Schleifenvariable ausserhalb der Schleife benutzen

[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?

[Luckie]

Ich wollte gerade sagen, akzeptieren wir es doch einfach, dass sie unbestimmt sein kann und nutzen sie einfach nach der Schleife nicht mehr.

[Delphi-Laie]

Zitat von Furtbichler:

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

Innerhalb der Schleife natürlich nicht, obwohl es durchaus sinnvolle Ausnahmen von dieser Regel geben könnte.

Außerhalb der Schleife ist es mit dem Artenschutz der Variable bei mir vorbei (s.o.), doch dort ist sie ohnehin keine Laufvariable.