Achtung. Optimierung beim Compiler

[DelTurbo]

Hi,

damit eventuell andere nicht in diese falle laufen poste ich mal was passiert wenn man die Optimierung an hat.

Eine gaaanz fiese sache ist, das schleifen rückwärts laufen können. Das spart ein cmp. In meinem fall ist das voll in die hose gegangen.

Beispiel:
Ich habe ein InUse = Array[0..100] of Boolean. Das wird von mehreren Threads genutzt. Und auch wieder frei gegeben. Mein Sourcecode war wie folgt.

Delphi-Quellcode:

for i:=0 to 100 do
begin
  if NOT InUse[i] then ....
end;

Ziel war es von "unten" einen leeren Slot zu suchen. Ich habe fast eine Stunde gebraucht bis ich rausfand das die schleifen rückwärts läuft. Man kann es nur im Assembler sehen.

Ändert man den Sourcecode wie folgt ab, läuft die schleife wieder richtigrum. Also von 0 bis 100

Delphi-Quellcode:

for i:=0 to 100 do
begin
  WriteLn(i);
  if NOT InUse[i] then ....
end;

Ich weiss nicht inwie weit diese sache bekannt ist. Auch habe ich eine frage dazu. Gibt es flags/parameter womit man teile des programms von der optimierung ausschliessen kann?

Gruss und danke im voraus

[s.h.a.r.k]

Schau mal hier.

Auf Delphi-Treff war mal ein guter Artikel dazu, finde den gerade aber nicht mehr.

PS: Thread solltest du auch ein einer T(Object)List verwalten, z.B.. Da hast du auch nicht das Problem einen freien Platz suchen zu müssen.

// edit
Soweit ich das noch weiß, optimiert der Compiler das dahingehend, da die CPU scheinbar leichter und schneller um 1 dekrementieren als inkrementieren kann. Aber einen Unterscheid sollte in deinem Programm nicht auftreten. Beim Debuggen findet du lediglich die "falschen" Werte, intern wird aber alles richtig ausgeführt.

// edit 2:
Hier, ganz unten findest du das auf Delphi Treff.

[jfheins]

Grund ist dass sehr einfach auf "=0" geprüft werden kann. ein "=100?" läuft also auf ein "x-100=0?" 'raus ;)

Aber eigentlich sollte die Compileroptimierung keine Änderung des Verhaltens zeigen - wie du richtig festgestellt hast, lässt der Compilrr die Schleife vorwärts laufen sobald es einen Unterschied macht (=> eine Ausgabe erzeugt o.ä.)

Kann mit
{O+} und {O-}
gesteuert werden

[JasonDX]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1027200)

Soweit ich das noch weiß, optimiert der Compiler das dahingehend, da die CPU scheinbar leichter und schneller um 1 dekrementieren als inkrementieren kann.

Nein, der Compiler optimiert die Schleife so, dass sie nicht von n..m, sondern von (n-m-1)..0 läuft. Da bei Operationen wie Inc- und Dekrementieren bereits das Zero-Flag gesetzt wird, wenn der Wert 0 wird, erspart man sich einen Vergleich pro Schleifendurchlauf.

Zitat:

Zitat von s.h.a.r.k (Beitrag 1027200)

Aber einen Unterscheid sollte in deinem Programm nicht auftreten. Beim Debuggen findet du lediglich die "falschen" Werte, intern wird aber alles richtig ausgeführt.

Ja, der Zugriff auf InUse[i] erfolgt in der richtigen Reihenfolge. Der Compiler speichert sich den Zeiger auf InUse[0], und inkrementiert diesen bei jedem Schleifendurchlauf, während der Index dekrementiert wird. Läuft insgesamt schneller, und das Array wird in der korrekten Reihenfolge abgearbeitet.

greetz
Mike

[hoika]

Hallo,

was mich eh interessiert.
Wieso hast du beim Debuggen die Optimierung angeschaltet ?


Heiko

[Luckie]

Wahrscheinlich, weil sie bei den Projektoptionen standardmäßig an ist.

[himitsu]

Über einige standardmäßige Sachen hatte ich mich ja schonmal beschwert.
- wenn standardmäßig auch noch Bereichsprüfungen, Überlaufprüfungen und Dergleichen aktiviert wären, dann gäbe es diesbezüglich wohl auch weniger Probleme bezüglich 0- und 1-Index, sowie Length()-1 usw.


Fakt ist einfach, daß man dem Debugger vergessen hat mitzuteilen, daß z.B. die Reihenfolge umzudrehen ist, bzw. daß der interne Wert anders interpretiert werden muß.

Bei Verwendung dieses Index wird er aber "richtig" angewand.
Sei es durch:

Delphi-Quellcode:

// dieses
for i := 0 to 10 do
  x := a[i];

// als
i := 10;
repeat
  x := a[10-i];
  Dec(i);
until {i = 0} ZeroFlag;

// oder 

i := 10;
p := @a[0]
repeat
  x := p^;
  Inc(p);
  Dec(i);
until {i = 0} ZeroFlag;

// oder (es gibt noch unzählige Möglichkeiten

[DelTurbo]

Zitat:

Zitat von jfheins (Beitrag 1027203)

Grund ist dass sehr einfach auf "=0" geprüft werden kann. ein "=100?" läuft also auf ein "x-100=0?" 'raus ;)

Ne, das ist so nicht richtig. Wie ich oben schrieb braucht es ein cmp (Assembler) weniger. Richtig rum sähe das so aus

mov [register+?],0 // Startwert
schleife:
inc [register+?] // Wert einen hochzählen
cmp [register+?],$5a // Vergleichen ob MAX erreicht ist.
jne schleife

nach der Optimierung sieht es so aus

mov [register+?],$5a // MAX Wert
schleife:
dec [register+?] // Einen vom MAX abziehen
jnz schleife // Wenn nicht 0 dann weiter

Das ist extra so "platt" geschrieben das auch leute die kein Assembler können es verstehen sollten.

Gruss

PS.: Danke, das mit dem {O+} und {O-} werde ich mir merken.

EDIT: Ich weiss nicht was ihr mit Debugger meint. Ich meine das CPU-Fenster. Da sieht man wirklich was abgeht.

[himitsu]

Zitat:

Zitat von DelTurbo (Beitrag 1027305)

PS.: Danke, das mit dem {O+} und {O-} werde ich mir merken.

Oder sieh dich mal in den Projektoptionen um. :zwinker::

Zitat:

Zitat von DelTurbo (Beitrag 1027305)

EDIT: Ich weiss nicht was ihr mit Debugger meint. Ich meine das CPU-Fenster. Da sieht man wirklich was abgeht.

Rate mal, wer dir Zugang zu diesem Fenster gewährt?

[DelTurbo]

Jo,

in den Projektoptionen habe ich das ja ausgemacht nachdem ich den salat gesehen habe. Es geht nur darum das man es dort z.b. Generell ausmacht und einzelne Proceduren optimiert. Oder halt andersrum.

Steht aber so auch in meinem ersten post.

Zitat:

Gibt es flags/parameter womit man teile des programms von der optimierung ausschliessen kann?

[SirThornberry]

Die Frage war eben ob es überhaupt notwendig ist an der Stelle die Optimierung abzuschalten. Denn wie bereits erwähnt wurde sollte sich die Optimierung nicht derart auswirken das eine falsche Logic entsteht.

[DelTurbo]

Zitat:

Zitat von SirThornberry (Beitrag 1027318)

Denn wie bereits erwähnt wurde sollte sich die Optimierung nicht derart auswirken das eine falsche Logic entsteht.

Macht es aber....

[Namenloser]

Dann kannst du ja den Bug melden, und wenn du Glück hast, wird der Fehler dann in Delphi 2012 behoben :-D [/Zynismus]

[himitsu]

Hab noch nie mitbekommen, daß es dadurch Probleme gibt.

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

var
  i: Integer;
  InUse: Array[0..20] of Boolean;
  Sr, S: String;
begin
  for i := 0 to 20 do
    InUse[i] := Boolean(Random(2));
  Sr := '';
  for i := 0 to 20 do begin
    // zählt problemlos rückwärts
    if not InUse[i] then Sr := Sr + 'j' else Sr := Sr + 'n';
  end;
  S := '';
  for i := 0 to 20 do begin
    WriteLn(i);
    if not InUse[i] then S := S + 'j' else S := S + 'n';
  end;
  WriteLn(Sr);
  WriteLn(S);
end.

[blauweiss]

Zitat:

Zitat von DelTurbo (Beitrag 1027329)

Zitat:

Zitat von SirThornberry (Beitrag 1027318)

Denn wie bereits erwähnt wurde sollte sich die Optimierung nicht derart auswirken das eine falsche Logic entsteht.

Macht es aber....

Ich traue mich einfach wetten, daß nicht.
DelTurbo, schau bitte nochmal genau hin. Leider gibt es dazu x Threads, wo das gleiche gemeldet+widerlegt wurde, und nicht ein Thread, wo es dann tatsächlich so war.

Nichtsdestotrotz ist diese Schleifen-Runterzähl-"Optimierung" m.E. weitgehend sinnlos. Performance geht tatsächlich verloren durch schlechtes Algorithmendesign oder Peripheriezugriffe, während ein gesparter Assemblerbefehl pro Durchlauf in einer Schleife zu 99.9999999% marginal ist.

blauweiss

[uligerhardt]

Zitat:

Zitat von DelTurbo (Beitrag 1027329)

Zitat:

Zitat von SirThornberry (Beitrag 1027318)

Denn wie bereits erwähnt wurde sollte sich die Optimierung nicht derart auswirken das eine falsche Logic entsteht.

Macht es aber....

Wie wäre es, wenn du mal ein kleines Beispielprogrämmchen bastelst, dass das mutmaßliche Fehlverhalten nachvollziehbar aufzeigt (und nicht nur im Debugger!)?

[DelTurbo]

Zitat:

Zitat von uligerhardt (Beitrag 1027348)

Wie wäre es, wenn du mal ein kleines Beispielprogrämmchen bastelst, dass das mutmaßliche Fehlverhalten nachvollziehbar aufzeigt (und nicht nur im Debugger!)?

Einfach mal den ersten beitrag lesen. Sobald es zu einer ausgabe kommt rennt die schleife richtigrum. Soll ich hier screenshots anhängen oder was?

@blauweiss, ich merke schon Assembler ist nicht deine Welt. Ich denke mal das du nicht weisst wieviel Taktzyklen in einer grossen schleife verloren gehen, oder überhaupt weisst was schneller ist. Ein MOV AX,0 oder ein XOR AX,AX.

Ausserdem wollte ich keine diskusuion über Assembler lostreten. Ich wollte das nur mitteilen damit andere nicht den gleichen "fehler" suchen.

[uligerhardt]

Zitat:

Zitat von DelTurbo (Beitrag 1027877)

Zitat:

Zitat von uligerhardt (Beitrag 1027348)

Wie wäre es, wenn du mal ein kleines Beispielprogrämmchen bastelst, dass das mutmaßliche Fehlverhalten nachvollziehbar aufzeigt (und nicht nur im Debugger!)?

Einfach mal den ersten beitrag lesen.

Du wirst's nicht glauben, aber das habe ich. :mrgreen:

Zitat:

Zitat von DelTurbo (Beitrag 1027877)

Sobald es zu einer ausgabe kommt rennt die schleife richtigrum. Soll ich hier screenshots anhängen oder was?

Nein. Ich werde aus deinen Ausführungen nur nicht schlau, ob du

• nur über die verkehrte Anzeige von i im Debugger stolperst oder
• ohne Debugger nachvollziehbare Fehler hast.

[DelTurbo]

Optimiert hat i den wert 88 nach der schleife. i wird runtergezählt.
Nicht Optimiert hat i den wert 3. i wird hochgezählt.

i ist im weiteren verlauf mein index auf ein anderes Array.

Na wenn das mal kein unterschied ist, weiss ich es nicht.

Edit: Das die bilder sooooo klein sind wusste ich nicht. Man kann es trotzdem lesen.
@uligerhardt, wenn ich ohne den debugger den fehler nicht gehabt hätte, hätte ich wohl kaum gesucht.

[p80286]

Zitat:

Zitat von DelTurbo (Beitrag 1027900)

Optimiert hat i den wert 88 nach der schleife. i wird runtergezählt.
Nicht Optimiert hat i den wert 3. i wird hochgezählt.

i ist im weiteren verlauf mein index auf ein anderes Array.

Na wenn das mal kein unterschied ist, weiss ich es nicht.

Edit: Das die bilder sooooo klein sind wusste ich nicht. Man kann es trotzdem lesen.
@uligerhardt, wenn ich ohne den debugger den fehler nicht gehabt hätte, hätte ich wohl kaum gesucht.

Eigentlich hätte eine Warnung auftauchen müssen,daß das I nach dem Schleifendurchlauf undefiniert ist.
Hast Du vielleicht die Warnungen unterdrückt?
Ist mir auch einmal passiert, und danach hab ich "for i:=" durch "while i=" ersetzt.

Gruß
K-H

[himitsu]

Dieses wurde doch garnicht bezweifelt?

Es wurde nur gesagt, daß die "Optimierung" das Programm-Verhalten nicht verändert,
wie du es (so klingt es zumindestens) ständig behauptest.
Und das ist bisher nirgendwo nachgewiesen wurden.

Fazit:
- intern kann sich die Zählreihenfolge mal verändern
- aber dennoch wird an der Arbeitsweise und dem Ergebnis des Programms nix verändert.


PS: Diese Optimierung muß nichtmal nur rückwärts zählen.

zählt von 6 auf 0 runter:
(natürlich nur in diesem Beispiel und mit Optimierung halbwegs garantiert)

Delphi-Quellcode:

var i, j: Integer;
begin
for i := 5 to 10 do
  inc(j);
if j = 0 then ;  // damit j nicht wegoptimiert wird
end;

zählt von -6 auf 0 rauf:

Delphi-Quellcode:

var i, j: Integer;
begin
for i := 10 downto 5 do
  inc(j);
if j = 0 then ;
end;

Und falls deine Schleifenvariable nach der Schleife einen "unerwarteten" Wert aufweist ... daran bist'e selbser Schuld, da eine Schleifenvariable nur innerhalb der Schleife gültig ist, welches der Compiler (wie auch schon erwähnt wurde) melden sollte.

[uligerhardt]

Zitat:

Zitat von himitsu (Beitrag 1027906)

Dieses wurde doch garnicht bezweifelt?

Es wurde nur gesagt, daß die "Optimierung" das Programm-Verhalten nicht verändert,
wie du es (so klingt es zumindestens) ständig behauptest.
Und das ist bisher nirgendwo nachgewiesen wurden.

Fazit:
- intern kann sich die Zählreihenfolge mal verändern
- aber dennoch wird an der Arbeitsweise und dem Ergebnis des Programms nix verändert.

Danke. Du hast das irgendwie prägnanter formuliert als ich. :-)

[Assertor]

Hallo,

Zitat:

Zitat von DelTurbo (Beitrag 1027900)

i ist im weiteren verlauf mein index auf ein anderes Array.

p80286 und himitsu haben absolut recht: Der Wert der Schleifenvariable ist nach der Schleife nicht garantiert, egal was Du machst. Um die Eingangsfrage zu beantworten: Ja, das Verhalten ist bekannt.

Die Herren Nick Hodges, Allen Bauer und Primoz Gabrijelcic schreiben es bei StackOverflow so:

Zitat:

That is correct. The variable is specifically documented to be undefined after the loop is complete. If you need a defined variable after the loop, use while or repeat – Nick Hodges Apr 9 at 22:45

Depending upon how the loop variable is used within the loop, the compiler may even eliminate it completely and simply use a pointer to iterate through the elements of an array, for example. – Allen Bauer Apr 10 at 0:02

... is undefined ... except if you terminate the loop with the 'break' statement. In that case, value is defined (the last value the loop counter had before the 'break' was executed). – gabr Apr 10 at 5:57

Der Sonderfall Break bzw. Exit wird von Gabrijelcic angerissen, in der Delphi Hilfe bzw. Daniels Delphi Referenz darauf wird das im Detail erörtert.

Gruß,
Assertor

[DelTurbo]

Hi,

Warnungen sind an. Nein es kommt keine warnung. Sonst hätte ich nicht suchen müssen sondern sofort gewusst was schief läuft.

Lasse ich die Optimierung an und mache zusätlich ein WriteLn(i); rein hat i auchwieder den "richtigen" wert. Da kann man dann auch schön sehen das die Optiemierung nicht gut ist. Statt es weiterhin in einem register zu machen, was beim call kurz gepusht wird, sieht der code aus als wäre er nicht optimiert.

Ich habe grad mal einen 3zeiler gemacht. Es kommt keine warung. Kann ja jeder mal durchjagen, der möchte.

Zum testen ob ich Hinweise und Warungen bekomme, (ich habe auch nun mind. 3x nachgesehen, die hacken sind drinn) hatte ich in dem Projekt noch i1 drinne und wollte das ausgeben. Da kommt denn ein Hinweis das es nicht initialisiert wurde.

Ich habe übrigens nicht D2005 sondern D7. Ob das eine rolle spielt weiss ich nicht. Mit dem neuen Board hier sieht man wohl nichtmehr welche version jemand nuzt. Und D7 kann man nicht einstellen.

EDIT:

Zitat:

Zitat von Assertor (Beitrag 1027916)

Um die Eingangsfrage zu beantworten: Ja, das Verhalten ist bekannt.

Das wusste ich nicht. Da ich ja blutiger anfänger bin und mich kaum im netz rumtreibe, laufen solchen speziellen info an mir vorbei.

Was ich eigentlich nur erreichen wollte ist, das nicht andere auf diese sache reinfallen. Und keines falls einen Thread erzeugen der nun 3 Seiten lang ist. Eigentlich war es nur als info gedacht.

[Klaus01]

Zitat:

Zitat von DelTurbo (Beitrag 1027196)

Beispiel:
Ich habe ein InUse = Array[0..100] of Boolean. Das wird von mehreren Threads genutzt. Und auch wieder frei gegeben. Mein Sourcecode war wie folgt.

Delphi-Quellcode:

for i:=0 to 100 do
begin
  if NOT InUse[i] then ....
end;

Ziel war es von "unten" einen leeren Slot zu suchen. Ich habe fast eine Stunde gebraucht bis ich rausfand das die schleifen rückwärts läuft. Man kann es nur im Assembler sehen.

Guten Abend DelTurbo,

so ganz verstehe ich die Aufregung nicht.
Ziel war es einen freien Slot zu finden, ob der nun näher bei der 0 oder bei der 100 liegt
dürfte dem Programmablauf doch relativ wurscht sein. Es soll doch nur ein freier Slot gefunden werden.


Grüße
Klaus

[DelTurbo]

Zitat:

Zitat von Klaus01 (Beitrag 1027963)

so ganz verstehe ich die Aufregung nicht.
Ziel war es einen freien Slot zu finden, ob der nun näher bei der 0 oder bei der 100 liegt
dürfte dem Programmablauf doch relativ wurscht sein. Es soll doch nur ein freier Slot gefunden werden.

Hier ist doch keine aufregung. Bitte schau dir den Assemblercode an.

Aber ich wiederhohlen gerne nochmal. Es ging legendlich darum, anderen usern die möglichkeit zu geben nicht in die selbe "falle" zu stolpern. Es war kein 3 Seitenlanger Thread geplant.

Hintergrund warum ich das gemacht habe: Wenn man etwas sucht, ist delphipraxis immer weit oben bei den treffen. (Ich hoffe nur das der googlebot schnell die links korrigiert) So gelangte ich damals auch hier her. Und ich merkte schnell das einem, auch wenn man anfänger ist, hier immer geholfen wird. An dieser stelle nochmals ein dickes lob an die Mod´s und den ganzen usern hier im Board.

Da meine "demo" schon 7x geladen wurde und keinerlei rückmeldung kommt, nehme ich an das auch bei anderen Delphi-versionen keine warnung kommt.

Wäre toll wenn dieses noch als rückmeldung käme. Ein satz reicht um hier nicht weiter abzugleiten.

[uligerhardt]

Zitat:

Zitat von DelTurbo (Beitrag 1028040)

Da meine "demo" schon 7x geladen wurde und keinerlei rückmeldung kommt, nehme ich an das auch bei anderen Delphi-versionen keine warnung kommt.

1. An deiner Demo kann man gar nicht sehen, ob die Suche "von oben" oder "von unten" läuft, weil du nur ein Element mit Wert True in MyArray hast. Erst, wenn man noch ein weiteres einfügt (z.B.
   Delphi-Quellcode:

   MyArray[7] := True;

   ), wird's aussagekräftig.
2. Ich habe Optimierung aktiviert. Trotzdem läuft i bei mir (D2007) im Debugger hoch und nicht runter.

Also irgendwie kann ich kein Problem feststellen. :-P

[Stevie]

Zitat:

Zitat von DelTurbo (Beitrag 1028040)

Da meine "demo" schon 7x geladen wurde und keinerlei rückmeldung kommt, nehme ich an das auch bei anderen Delphi-versionen keine warnung kommt.

Wäre toll wenn dieses noch als rückmeldung käme. Ein satz reicht um hier nicht weiter abzugleiten.

Es kommt keine Warning, weil du mit Break aus der Schleife gehst und daher i einen definierten Wert hat (wie oben schon zitiert wurde). Hast du kein break, wird eine Warning ausgegeben. Und in der Tat steht bei mir i dann auf 10, obwohl laut der Schleife nur von 0 bis 9 gelaufen wird.

Zitat:

Zitat von uligerhardt (Beitrag 1028070)

1. An deiner Demo kann man gar nicht sehen, ob die Suche "von oben" oder "von unten" läuft, weil du nur ein Element mit Wert True in MyArray hast. Erst, wenn man noch ein weiteres einfügt (z.B.
   Delphi-Quellcode:

   MyArray[7] := True;

   ), wird's aussagekräftig.
2. Ich habe Optimierung aktiviert. Trotzdem läuft i bei mir (D2007) im Debugger hoch und nicht runter.

Also irgendwie kann ich kein Problem feststellen. :-P

Im Debugger sieht man auch nix vom rückwärts laufen, sondern nur im asm code (wurde auch im Eingangspost erwähnt)

[uligerhardt]

Zitat:

Zitat von Stevie (Beitrag 1028072)

Im Debugger sieht man auch nix vom rückwärts laufen, sondern nur im asm code (wurde auch im Eingangspost erwähnt)

Ach, da war ich wohl im Überschwang des vermeintlichen Erfolgs zu schnell.:oops:

[DelTurbo]

Zitat:

Zitat von p80286 (Beitrag 1027904)

Eigentlich hätte eine Warnung auftauchen müssen,daß das I nach dem Schleifendurchlauf undefiniert ist.

Mir ging es darum. Ob andere Delphi´s eine warnung auspsucken, wie p80286 beschreibt. Diese "demo" ist nur für diesen zweck.

Zitat:

Zitat von Stevie (Beitrag 1028072)

Es kommt keine Warning, weil du mit Break aus der Schleife gehst und daher i einen definierten Wert hat (wie oben schon zitiert wurde). Hast du kein break, wird eine Warning ausgegeben. Und in der Tat steht bei mir i dann auf 10, obwohl laut der Schleife nur von 0 bis 9 gelaufen wird.

Danke

[Assertor]

Zitat:

Zitat von DelTurbo (Beitrag 1027954)

EDIT:

Zitat:

Zitat von Assertor (Beitrag 1027916)

Um die Eingangsfrage zu beantworten: Ja, das Verhalten ist bekannt.

Das wusste ich nicht. Da ich ja blutiger anfänger bin und mich kaum im netz rumtreibe, laufen solchen speziellen info an mir vorbei.

Was ich eigentlich nur erreichen wollte ist, das nicht andere auf diese sache reinfallen. Und keines falls einen Thread erzeugen der nun 3 Seiten lang ist. Eigentlich war es nur als info gedacht.

Macht doch nichts, jeder hat mal angefangen... Aber in der DP hättest Du das auch finden können (sf Optimierung, Schleife):
http://www.delphipraxis.net/89407-co...mierung-2.html
http://www.delphipraxis.net/122117-v...definiert.html

Es soll auch im Delphi Language Guide stehen, das habe ich jetzt aber nicht nachgesehen.

Ich habe Dein Beispiel gerade getestet: Es bringt keine Warnung unter Delphi 2010. Das liegt daran, dass es ja genau der dokumentierte Sonderfall ist, den ich zuvor erwähnte (siehe aktuellere Delphi Hilfe).

Es gibt ohne Break auf jeden Fall eine Warnung:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  i: Integer;
  j: Integer;
begin
    MyArray[5]:=True;
    for i:=low(MyArray) to high(MyArray) do begin
      // if MyArray[i] then break;
      j := i;
    end;
    Label1.Caption:='i ist:'+IntToStr(i);
end;

Bringt:

Zitat:

[DCC Warning] Unit1.pas(37): W1037 FOR-Loop variable 'i' may be undefined after loop

Gruß,
Assertor

[Stevie]

Zitat:

Zitat von Stevie (Beitrag 1028072)

Im Debugger sieht man auch nix vom rückwärts laufen, sondern nur im asm code (wurde auch im Eingangspost erwähnt)

Korrektur: Sofern man i nicht innerhalb der Schleife verwendet, kann man auch im Debugger sehen, dass runtergezählt wird. Verwendet man i nach der Schleife (trotz warning) kann es vorkommen, dass nicht abwärts gezählt wird. Der Wert von i nach der Schleife stimmt trotzdem nicht.

[DelTurbo]

Zitat:

Zitat von Assertor (Beitrag 1028087)

Ich habe Dein Beispiel gerade getestet: Es bringt keine Warnung unter Delphi 2010.

Danke, das ist genau das was ich wissen wollte.