Head scratcher
Nico de Jong
I'm hardly a novice in Delphi 4, but this one is beyond me.
---------------------------------------
assignfile(tekst,strg);
rewrite(tekst);
for ix := 1 to nbr_elem do
begin
str(ix,strg);
move(nbc_arr[ix],strx[1],sizeof(tnbcrecord));
writeln(tekst,strx);
end;
closefile(tekst);
------------------------------
When the line STR(IX,STRG) is absent, IX will be 100 (nbr_elem is a
Constant) when I get to the MOVE first time, and IX will be decremented
afterwards.
When the line _is_ present, the code functions as expected.
IX is defined as a local variable (integer), STRG is a local string, STRX is
a local string with size(tnbcrecord) (190).
Any ideas on what is happening?
Nico
Jud McCranie
wrote:
>When the line STR(IX,STRG) is absent, IX will be 100 (nbr_elem is a
>Constant) when I get to the MOVE first time, and IX will be decremented
>afterwards.
>When the line _is_ present, the code functions as expected.
...
>Any ideas on what is happening?
Without testing it, it looks to me that the compiler is optimizing the
loop to count the index (ix) down, and not realizing that ix is used
in the loop, without the str() line. It optimizes loops that way, if
it doesn't affect the outcome, but it seems to be missing the use if
ix in the Move statement. That's my guess. If you have O+
(optimization on) see what happens with O- (I don't know if it will
have an effect.) This may be fixed in a newer version.
---
Replace you know what by j to email
Nico de Jong
news:83tcs0dome6h092lp...@4ax.com...
> On Mon, 20 Dec 2004 07:36:10 +0100, "Nico de Jong" <ni...@farumdata.dk>
> wrote:
>
> >When the line STR(IX,STRG) is absent, IX will be 100 (nbr_elem is a
> >Constant) when I get to the MOVE first time, and IX will be decremented
> >afterwards.
> >When the line _is_ present, the code functions as expected.
> ...
> >Any ideas on what is happening?
>
> Without testing it, it looks to me that the compiler is optimizing the
> loop to count the index (ix) down, and not realizing that ix is used
> in the loop
That was the reason. I removed the Optimization function, and it worked as
hoped.
Nasty error!
Thanks
Nico
Bruce Roberts
"Nico de Jong" <ni...@farumdata.dk> wrote in message
news:bpuxd.262$Cb1...@news.get2net.dk...
> assignfile(tekst,strg);
> rewrite(tekst);
> for ix := 1 to nbr_elem do
> begin
> str(ix,strg);
> move(nbc_arr[ix],strx[1],sizeof(tnbcrecord));
> writeln(tekst,strx);
> end;
> closefile(tekst);
> ------------------------------
>
> When the line STR(IX,STRG) is absent, IX will be 100 (nbr_elem is a
> Constant) when I get to the MOVE first time, and IX will be decremented
> afterwards.
How are you determining this? If you are using the debuger you might want to
check out the mini-FAQ question that deals with this issue.
VBDis
<ni...@farumdata.dk> schreibt:
>That was the reason. I removed the Optimization function, and it worked as
>hoped.
>Nasty error!
Did you really encounter an error? Inspecting variables may give wrong values
with optimized code, but the code itself should work as expected.
DoDi
Jud McCranie
>Did you really encounter an error? Inspecting variables may give wrong values
>with optimized code, but the code itself should work as expected.
He's having it write to a file, so I assumed that he was looking at
the file it writes. I could be wrong, though.
Nico de Jong
"VBDis" <vb...@aol.com> skrev i en meddelelse
news:20041221154836...@mb-m01.aol.com...
value in the first field of the first record, so whatever I got written, it
was surely not # 1. Also, when having a breakpoint just before the write
statement, I could see that IX had the contents 100
Nico
Marco van de Voort
Show your strx definition.
It should be should be strx:shortstring[190]; (or larger).
It sounds like the move moves too much and overwrites ix. This isn't a problem
if ix is written in each iteration by the str statement.
P.s. Always try to make example code as compilable as possible.
Bruce Roberts
"Nico de Jong" <ni...@farumdata.dk> wrote in message
news:nV6yd.3$pd...@news.get2net.dk...
> Yes I got written the "wrong" record to start with. I had a distinctive
> value in the first field of the first record, so whatever I got written,
it
> was surely not # 1. Also, when having a breakpoint just before the write
> statement, I could see that IX had the contents 100
Without declarations for the variables being used its difficult to suggest
what may be wrong. However, I'm always suspicious of Move when I get
unexpected results. Its quite low level and very literal. One has to be
careful that one is actually moving data and not references to data. Also,
as the mini-FAQ points out, one cannot count on debug displaying the
"correct" value for a loop control variable inside of a For loop. The
compiler may optimize code in a way that the debugger seems incapable of
understanding. The net result is that the debugger may show the loop control
variable counting down, when in fact it is incrementing.