For-Schleife von 0 bis 7 fängt bei 8 an

[Luckie]

Nach einer for Schleife ist die Zählvariable undefiniert. Die Speicherstelle hat wohl nur zufällig den Wert 8. Der Compiler sollte eine entsprechende Warnung ausgegeben haben.

[Hansa]

Die Zählvariable hat immer einen um 1 erhöhten Wert außerhalb der Schleife. Das ist kein Zufall. Der Compiler meckert nur, wenn innerhalb der Schleife sogar noch ein Wert a la i := i + 1; zugewiesen wird. Wie gesagt, ich weiß auch nicht warum, aber es ist egal. Das müßte ein Compiler-Bauer sagen. Und dabei käme wohl eine Diskussion zustande, daß intern ein SHL oder sonstein ASM Befehl genutzt wird, aus Performancegründen und, daß der Compiler in die Knie gehen würde, falls man den Wert auf den letzten der in der Schleife tatsächlich genutzten Werte zurücksetzt und, daß das auch überflüssig ist, da die Variable ja sowieso auf die Schleife beschränkt bleiben soll.

[Neutral General]

Zitat von Hansa:

Die Zählvariable hat immer einen um 1 erhöhten Wert außerhalb der Schleife. Das ist kein Zufall.

Würde mich ja mal interessieren warum das so ist

[jim_raynor]

Zitat von Neutral General:

Zitat von Hansa:

Die Zählvariable hat immer einen um 1 erhöhten Wert außerhalb der Schleife. Das ist kein Zufall.

Würde mich ja mal interessieren warum das so ist

Ich glaube ehr, dass es nicht so ist. Wenn du die Zählvariable in der Schleife nicht benutzt, wird diese ja (wie wir in diesem Beitrag gelernt haben) Abwärts gezählt. Somit wirst du am Ende auf einen anderen Wert deiner Schleifen-Variable kommen. Logisch wäre dann, wenn in der Zählvariable ne 0 drin stehen würde, aber auch das ist wahrscheinlich nicht so, da zum Zählen nicht unbedingt die Variable sondern einfach nur ein CPU-Register benutzt wird. Deshalb kommt auch die besagte Warnung, dass der Wert nach einer Schleife undefiniert ist.

[Luckie]

Zitat von Hansa:

Der Compiler meckert nur, wenn innerhalb der Schleife sogar noch ein Wert a la i := i + 1; zugewiesen wird. Wie gesagt, ich weiß auch nicht warum, aber es ist egal.

Ich weiß nicht, was du für einen Compiler hast, aber meiner sagt mir:

Zitat:

[Warnung] Unit1.pas(31): FOR-Schleifenvariable 'i' kann nach Durchlauf undefiniert sein

Und dass man innerhalb einer Schleife so nicht die Zählvariable manipulieren kann, ist allseits bekannt.

[Chewie]

Zitat von Luckie:

Und dass man innerhalb einer Schleife so nicht die Zählvariable manipulieren kann, ist allseits bekannt.

Naja, aber nicht bei C, Java, etc. Dort ist das schon möglich. In Pascal ist das, will man keine Warnung produzieren, nur über den Zeiger-Umweg möglich. Warum, würde mich auch interessieren, ich vermute aber aufgrund der mathematisch-logischen Orientierung von Pascal.

Zitat von Neutral General:

Zitat von Hansa:

Die Zählvariable hat immer einen um 1 erhöhten Wert außerhalb der Schleife. Das ist kein Zufall.

Würde mich ja mal interessieren warum das so ist

Gehen wir mal von folgender (nicht-optimierten) for-Schleife aus:

Delphi-Quellcode:

for i := 0 to 7 do
begin
end;

Diese könntest du (unter Erzeugung des prinzipiell gleichen Maschinencodes) in folgende while-Schleife umwandeln:

Delphi-Quellcode:

i := 0;
while i <= 7 do
begin
  Inc(i);
end;

Ist jetzt klar, warum?

[PRehders]

Zitat von Neutral General:

Zitat von Hansa:

Die Zählvariable hat immer einen um 1 erhöhten Wert außerhalb der Schleife. Das ist kein Zufall.

Würde mich ja mal interessieren warum das so ist

Wenn man Optimierungen (wie die Umkehrung des Schleifendurchlaufs) mal beseite lässt, ist die Erklärung recht einfach: Da bei einer For-Schleife der untere Grenzewert ja vorab bereits höher sein kann als der obere (bei Verwendung von Variablen für diese Werte), wird eine For-Schleife immer als abweisende Schleife gebaut, also die Abbruchbedingung wird vorab geprüft.
Nach dem Schleifendurchlauf wird die Zählvariable erhöht und wieder an den Anfang (die Prüfung!) gesprungen. Daher muss die Zählvariable nach dem Ende der Schleife um eins höher sein als der Abbruchwert.

Die Optimierungen des Compilers können dies natürlich ändern, aber nur dann, wenn die Zählvariable entweder nicht oder in einer sog. inavarianten Weise benutzt werden: Wird ein Array mit konstanten oder nicht von der Zählvariablen abhängigen Werten gefüllt, kann der Compiler das Füllen auch umdrehen und ggf. nur ein Register benutzen, so dass der Wert nach dem Schleifendurchlauf überhaupt nicht mehr existiert.
Dies jedoch beruht alles auf der Forderung von Pascal, dass die Zählvariable bzw. der Inhalt nach dem Schleifendurchlauf nicht mehr definiert ist!

Viel Spaß noch

Peter

[Flogo]

Zitat von Luckie:

Das ist wohl schon die korrigierte Fassung.

Nicht direkt! Der Schleifenkopf ist der gleiche wie in meinem Programm und die Array-deklaration ist bis auf den Typ auch die gleiche (bei mir war es TPoint)
Dass der Code, den ich gepostet habe, läuft, will ich gar nicht bezweifeln. Nur kam eben bei mir eine AV.
Die Zuweisung war bei mir noch anders (eben ein Point) und es wurden noch ein paar andere Sachen, die nichts mit i oder dem Array zu tun hatten, in der Schleife erledigt.
Leider hab ich den fehlerhaften Code nicht mehr sonst würde ich auch den hier posten. Das vorhin war nur als Beispiel gedacht, damit ihr seht, wie mein Array und meine For-Schleife aufgebaut sind.
So wie ich die Diskussion hier lese (hätte nie gedacht, dass das so ein großes Thema wird ) denke ich, dass der Fehler bei mir gar nicht in der Schleife lag, sondern irgendwo vorher.
Denn auch wenn als Hint [i = 8] und [Array[i] = inaccessable Value] angezeigt wurden, müsste das intern so geregelt werden, dass trotzdem der richtige Wert benutzt wird (-> Link von jim)

[jbg]

Zitat von Chewie:

Naja, aber nicht bei C, Java, etc. Dort ist das schon möglich. In Pascal ist das, will man keine Warnung produzieren, nur über den Zeiger-Umweg möglich.

Also bei Pascal geht das wunderbar. Nur Object Pascal und sein Nachfolger Delphi (Language) machen da nicht mit.

Unter TurboPascal konnte man noch folgende schöne, sehr lang dauernde Schleife programmieren:

Delphi-Quellcode:

for i := 0 to 2 do
  Inc(i);

Zitat:

Warum, würde mich auch interessieren, ich vermute aber aufgrund der mathematisch-logischen Orientierung von Pascal.

Der Hauptgrund wird wohl die Code-Optimierung gewesen sein.

[negaH]

Zitat von jbg:

Zitat von negaH:

Die dazu benutzen Befehle sind NICHT schneller als die Befehle des unoptimierten Codes, das ist ein Irrtum.

Ein CMP ist eine SUB Anweisung wo das Ergebnis verworfen und nicht in ein Register geschrieben wird. Und ich bin da schon der Meinung, wenn das Programm keine tzsätzliche Substraktion ausführen muss, dass es ein klein wenig schneller läuft. Und wenn dann die Zählervariable nicht in ein Register eingelagert werden kann, dann ist da auch noch ein Speicherzugriff mehr. Und bei einer Schleife, die mehrere Tausend male durchlaufen wird, macht sich das dann doch leicht bemerkbar.

Du hast mich falsch verstanden

Ein zusätzlicher Befehl wie CMP kostet mehr Taktzyklen pro Schleife, trotzdem ist ein CMP genauso schnell wie ein SUB oder DEC. Zählt die Schleife gegen Null mit dem Befehl DEC so benötigt man nach dem DEC bei Überprüfung auf Null kein zusätzliches CMP mehr sondern kann die Flags direkt auswerten.
D.h. also die Zählweise gegen Null spart einen zusätzlichen Befehl. Die Befehle selber sind meistens gleich schnell ausgeführt !!

Gruß Hagen