Board index » delphi » Delphi 3 and for statement problem

Delphi 3 and for statement problem

The for statement doesn't work as documented or like it did in previous
versions of Delphi and Turbo Pascal.

Specifically, in the statement
for i := InitalValue to FinalValue do
Begin
...
end;
the control variable i should get assigned InitalVale and incremented to
FinalValue for each loop iteration.  Instead, i gets assigned the
FinalValue and is decremented to the InitalValue.

I first observed this in a watch window and then confirmed this behavior
in the CPU widnow.

I use the control variable in my code and require it to be ascending for
each loop iteration, not descending. The work around is a kludge.

Am I missing something or is this a bug?

JerryG

 

Re:Delphi 3 and for statement problem


Note: I did not test it, but I read that the same 'problem' existed
in Delphi 2, due to the optimizer, who creates a faster loop by
decrementing
instead of incrementing, which is faster in assembler (costs one less
instruction or something) However, the optimizer should only do this
when the loopvariable itself is not accessed in the loop, because then
obviously, the result would be different when you decrement! I don't
know about D3 though...(haven't got it yet)
hope this helps!

Mike.

Re:Delphi 3 and for statement problem


Quote
Jerry Grant wrote:

> The for statement doesn't work as documented or like it did in previous
> versions of Delphi and Turbo Pascal.

> Specifically, in the statement
> for i := InitalValue to FinalValue do
> Begin
> ...
> end;
> the control variable i should get assigned InitalVale and incremented to
> FinalValue for each loop iteration.  Instead, i gets assigned the
> FinalValue and is decremented to the InitalValue.

> I first observed this in a watch window and then confirmed this behavior
> in the CPU widnow.

> I use the control variable in my code and require it to be ascending for
> each loop iteration, not descending.

        I would have thought the optimizer would do this, _if_ it was
clear that it didn't matter. Can you give a specific example of code
where it's important to count up instead of down but the compiler
counts down instead?

        (If otoh you're having problems with the value of i after the
loop terminates, the solution is don't so that - the value of the loop
variable is quite explicitly stated to be "undefined" after the loop
terminates, so if that's causing a problem the bug is in the code.)

--
David Ullrich

?his ?s ?avid ?llrich's ?ig ?ile
(Someone undeleted it for me...)

Re:Delphi 3 and for statement problem


In article <33788CAC...@math.okstate.edu>, ullr...@math.okstate.edu
says...

Quote
> Jerry Grant wrote:

> > The for statement doesn't work as documented or like it did in previous
> > versions of Delphi and Turbo Pascal.

> > Specifically, in the statement
> > for i := InitalValue to FinalValue do
> > Begin
> > ...
> > end;
> > the control variable i should get assigned InitalVale and incremented to
> > FinalValue for each loop iteration.  Instead, i gets assigned the
> > FinalValue and is decremented to the InitalValue.

> > I first observed this in a watch window and then confirmed this behavior
> > in the CPU widnow.

> > I use the control variable in my code and require it to be ascending for
> > each loop iteration, not descending.

>    I would have thought the optimizer would do this, _if_ it was
> clear that it didn't matter. Can you give a specific example of code
> where it's important to count up instead of down but the compiler
> counts down instead?

>    (If otoh you're having problems with the value of i after the
> loop terminates, the solution is don't so that - the value of the loop
> variable is quite explicitly stated to be "undefined" after the loop
> terminates, so if that's causing a problem the bug is in the code.)

> --
> David Ullrich

> ?his ?s ?avid ?llrich's ?ig ?ile
> (Someone undeleted it for me...)

David,
My error. The optimizer causes the behavior I described but only when the
loop variable is not used inside the for loop. Otherwise, it works as
expeceted.
Jerry G.

Re:Delphi 3 and for statement problem


Quote
Luke Webber wrote:

> David Ullrich <ullr...@math.okstate.edu> writes:
> >       I would have thought the optimizer would do this, _if_ it was
> >clear that it didn't matter. Can you give a specific example of code
> >where it's important to count up instead of down but the compiler
> >counts down instead?

> Yes, I can imagine *why* the optimiser would choose to do it as well. If
> you count down toward zero, you can test the zero flag after the
> decrement operation without having to do a load and compare. I used to
> specifically do decrementing loops in C for just that reason.

TP, and Delphi, support both
  for i := 1 to 10
and
  for i := 10 downto 1;

Re:Delphi 3 and for statement problem


Quote
David Ullrich <ullr...@math.okstate.edu> writes:
>    I would have thought the optimizer would do this, _if_ it was
>clear that it didn't matter. Can you give a specific example of code
>where it's important to count up instead of down but the compiler
>counts down instead?

Yes, I can imagine *why* the optimiser would choose to do it as well. If
you count down toward zero, you can test the zero flag after the
decrement operation without having to do a load and compare. I used to
specifically do decrementing loops in C for just that reason.

I sometimes wonder why Pascal won't allow the use of an integer in place
of a boolean in a conditional, but I suppose that's just the old C
mindframe tripping me up.

--
Luke Webber

* Note: The opinions expressed by Luke Webber are in no way supported *
*       by his employers, Luke Webber Consulting Services             *

Re:Delphi 3 and for statement problem


Quote
Luke Webber wrote:

> David Ullrich <ullr...@math.okstate.edu> writes:
> >       I would have thought the optimizer would do this, _if_ it was
> >clear that it didn't matter. Can you give a specific example of code
> >where it's important to count up instead of down but the compiler
> >counts down instead?

> Yes, I can imagine *why* the optimiser would choose to do it as well. If
> you count down toward zero, you can test the zero flag after the
> decrement operation without having to do a load and compare. I used to
> specifically do decrementing loops in C for just that reason.

> I sometimes wonder why Pascal won't allow the use of an integer in place
> of a boolean in a conditional, but I suppose that's just the old C
> mindframe tripping me up.

You can use an integer in a conditional by casting

ByteBool        1 byte
WordBool        two bytes (one word)
LongBool        four bytes (two words)

Just in case you didn't know already.

Mark

Other Threads