Schleifenvariable ausserhalb der Schleife benutzen

[Delphi-Laie]

Zur Ehrenrettung des Compilers sei gesagt: Eine diesbezügliche (berechtigte!) Warnung gibt der Compiler schon bei Delphi 2.0 aus (die Version 1 kann ich dahingehend nicht prüfen, habe sie nicht installiert), vielleicht war das sogar zu Turbo-Pascal-Zeiten schon implementiert....schnell mal eben Turbo-Pascal 6.0 (nie wieder einen solch schnelle und stabile IDE wahrgenommen) gestartet: Dort gibt es keine solche Warnung, und die Variable hat auch den Wert, der ihr zum Ende der Schleife (also zum Start des letzten Schleifendurchlaufes) mit auf den Weg gegeben wurde.

[himitsu]

Der Grund ist ganz einfach:

OK, wenn man die schleife abbricht, dann hat die Variable diesen letzten Wert, aber wie ist das, wenn die Schleife sich ordentlich beendet?

Hat die dann den letzen Wert
- erst prüfen, dann weiterzählen und danach zurückspringen
- erst prüfen, dann zurückspringen und danach weiterzählen
oder ist sie da schon weiter?
- weiterzähen, prüfen ob noch im Bereich dann verlassen oder zurückspringen

PS: Intern läuft die Variable auch manchmal rückwärts, oder eben aus Optimierungsgründen irgendwie anders.
Sie wird dann innerhalb der Schleife umgerechnet, bei deren Nutzung (falls sie überhaupt genutzt wird).

Aber auchßerhalb der Schleife gibt es diese Umrechnung nicht mehr.



Da nun also die Variable nicht unbedingt den Wert hat, welchen man sich vorstellt, kann man dieses danach einfach nicht nutzen,
bzw. manchmal gibt es diese Variable nicht wirklich lange (im RAM), da die nur kurz in einem CPU-Register drin lag.

Und jetzt auf den blosen Verdacht hin, daß diese irgendwer nachher noch verwenden könnte, schaltet der Compiler hier eben nicht alle Optimierungen ab.
Oder komt gar auf die Idee alle Zählervariablen, nach der Schleife, nochmal auf deren "wirklichen" Wert umzurechnen, was reichlich sinnlos wäre und überall einen nutzlosen Overhad bedeuten würde.



Lösung: Geh zu Emba ins EDN, erstelle einen Antrag (QC), man möge doch bitte statt dieser Fehlermeldung eine Umrechnung der Variable einbauen, bzw. dafür sorgen, daß deren Wert in eine richtige Variable kopiert wird.

[Bummi]

@himitsu

ich hatte gestern ein paar Szenarien durchgespielt, egal was man wann wo dazwischengemogelt hat, auch Schleifen dir nachprüfbar wegen Nonseneinhalten wegoptimiert werden, mit/ohne Optimierung etc. stand nach einem for 1 to 10 die Variable immer auf 11.
Wenn man die Anhänge von mir und DeddyH richtig interpretiert, hat der Compiler genügend Intelligenz an solchen Stellen die Optimierung nicht durchzuführen.

Aber eigentlich ist die ganze Diskussion müssig, weil wir alle seit Jahren anders arbeiten ....

[himitsu]

Jupp, könnte sein, daß der Compiler inzwischen intelligent genug ist.
Diese Meldung ist ja schon historisch alt.

Darum ja der Vorschlag mit dem QC.

[p80286]

Meiner Erfahrung nach ist i am Ende der for-Schleife dann nicht definiert, wenn i nicht für weitere Operationen (inc(j,i); ) heran gezogen wird.
Falls i nach der Schleife noch genutzt wird, nutze ich Repeat .. until oder while, was in den meisten Fällen auch besser lesbar ist.
(Arrays in Records etc. )



Gruß
K-H

[Furtbichler]

Sagt mal, der Compiler wird ja wohl nicht so dämlich sein, und den Variableninhalt überschreiben, bevor auf ihn zugegriffen wird.

Delphi-Quellcode:

For i:=1 to 10 do SomethingWith(i);
//
// Einige Zeit später
//
Writeln(i);

Muss immer funktionieren. Es ist eben nur so, das entweder die 0 oder 11 drin steht (denke ich). Deshalb 'unbestimmt'.

[Bummi]

es steht immer die 11 drin...

[stahli]

Ich hatte das mal getestet:

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
var
  I: Integer;
begin
  for I := 0 to Memo1.Lines.Count - 1 do
    Memo2.Lines.Add(Memo1.Lines[I]);
  Memo2.Lines.Add('->' + IntToStr(I));
end;

Wenn Count = 0 ist (also bis -1 bzw. gar nicht gezählt wird) enthält I einen Zufallswert (124567 o.ä.).

Es wäre ja nicht schlecht, wenn der Compiler wenigstens -1 in I schreiben würde, aber da lässt sich natürlich drüber streiten.
Jedenfalls wäre es nicht schädlich und würde weniger Probleme verursachen.

[Delphi-Laie]

Zitat von Furtbichler:

Sagt mal, der Compiler wird ja wohl nicht so dämlich sein, und den Variableninhalt überschreiben, bevor auf ihn zugegriffen wird.

Delphi-Quellcode:

For i:=1 to 10 do SomethingWith(i);
//
// Einige Zeit später
//
Writeln(i);

Muss immer funktionieren. Es ist eben nur so, das entweder die 0 oder 11 drin steht (denke ich). Deshalb 'unbestimmt'.

Der Compiler ist nicht dämlich, weil er nichts verändert, sondern erst das Programm (Compilat), wenn es läuft.

Wie Bummi es schon erwähnt: Der Wert um eins höher. Wird also nach der letzten Schleife noch einmal um 1 erhöht, um dann festzustellen, daß die (For-)Schleifenbedingung nicht mehr erfüllt ist -> Schleifenabbruch.

Der - in dieser Hinsicht intelligente - Compiler gibt zudem einen Warnhinweis aus: "For-Schleifenvariable kann nach Durchlauf undefiniert sein".

[Furtbichler]

Ja ja, in dem einen Fall ist die Schleifenvariable um eins höher, is schon klar. Aber was ist, wenn der Compiler so optimiert, das rückwärts gezählt wird? Steht dann auch 11 drin?

Ich glaube nicht (hab kein Delphi), und daher ist der Inhalt eben 'unbestimmt', weil manchmal so, manchmal so.

Dessenungeachtet ist es irrelevant, denn wir fassen die Laufvariable eh nicht an, gelle?