In Delphi, consider
var
i: integer;
begin
for i := 0 to N do
begin
{ Code }
end;
One might think that i = N after the for loop, but does the Delphi compiler guarantee this? Can one make the assumption that the loop variable is equal to its last value inside the loop, after a Delphi if loop?
Update
After trying a few simple loops, I suspect that i is actually equal to one plus the last value of i inside the loop after the loop... But can you rely on this?
No, Delphi does not guarantee any value. Outside the loop, the variable is undefined - and IIRC the Language Guide excplicitly state so - that means that newer compiler implementations are free to change whatever value the variable may have outside the loop due to the actual implementation.
break, the control variable's value will be valid. Likewise if you leave the loop with exit. The documentation says so. Undocumented, but still generally accepted as true, is that leaving the loop via raise or goto will also preserve the variable's value. –
Filly exit) can be placed inside a try...finally block, and so upon executing exit you still have an opportunity to (try to) read the counter's value before leaving the procedure. Still, not a very common scenario, probably. –
Cene The compiler actually emits a warning if you use the loop variable after the loop, so you should consider it undefined.
I would suggest that using a while loop is clearer if you need to use the loop index after the loop:
i := 0;
while i <= N
begin
{ Code }
i := i + 1;
end;
After that loop terminates, you know that i will be N + 1 (or greater, if N could have been less than zero).
Inc(i) instead of i := i + 1, but IIRC the compiler will treat them the same anyway. –
Intercommunion It is even documented that the loop variable from a for loop is undefined outside the loop.
In practice: What you get from the variable varies depending on compiler settings and code complexity. I have seen changes in code push the compiler into a different optimization path, therefore modifying the value of this undefined variable.
--jeroen
As many people stated, the I variable is supposed to be undefined after the loop. In real world usage, it will be defined to the last value it had before you "break", or to N + 1 if loop run to term. That behavior cannot be relied on though, as it's clearly specified it's not meant to work.
Also, sometimes, I won't even be assigned. I encountered this behavior mostly with optimisation turned ON.
For code like this
I := 1234;
For I := 0 to List.Count - 1 do
begin
//some code
end;
//Here, I = 1234 if List.Count = 0
So... If you want to know the value of I after the loop, it's better practice to assign it to another variable before going out of the loop.
NEVER EVER rely on the value of the for variable, after the loop.
Check your compiler output. Delphi compiler warns you about that. Trust your compiler.
raise an exception inside the function, or if you mix the Exit(ReturnValue) method with the old-school result := method. –
Fun As its been stated before, its undefined and can behave funnily if the variable has a value assigned before the for loop. If you exit the for loop with a Break; then the value is correct in all cases.
In our experience, in FreePascal, the value of the loop variable tends to be the "to" value, but in embarcadero (former borland), the value is often "to" + 1.
I wonder why no pascal compiler gives you even a warning regarding this issue, as its going to cause certain mayhem.
© 2022 - 2024 — McMap. All rights reserved.
forloop? I would check this first - because I suspect it may not be. – ClaspingNwill be in scope after the loop because it was obviously in scope before the loop (or else the code wouldn't have compiled). Scope in Delphi doesn't change mid-function; it starts at the start of a function and ends at the end. – Filly