for Schleife hat unterschiedliche Werte ???

[F.W.]

Hallo! Ich habe mal wieder eine Beobachtung gemacht:


Erstmal der Quellcode:
(Es soll geprüft werden, ob in einem Dateinamen ein Wochentag steckt)

Delphi-Quellcode:

procedure TMain.Log(S: String);
begin
 Memo.Lines.Add(S);
end;

  { ... }

const
  Days: Array[0..6] of String = ('Montag',
                                 'Dienstag',
                                 'Mittwoch',
                                 'Donnerstag',
                                 'Freitag',
                                 'Samstag',
                                 'Sonntag');

 { ... }

 for I := Low(Days) to High(Days) do begin
     if Pos(UpperCase(Days[I]), FN) = 5 then begin
{->        Log(Inttostr(I)+':  '+Days[I]);  }
        FileDatum.Tag := Copy(FN, 1, 2);
        FileDatum.monat := Copy(FN, 3, 2);
        FileDatum.Jahr := IntTostr(YearOf(Date));
        FileDate := StrTODate(Filedatum.Tag+'.'+Filedatum.Monat+'.'+FileDatum.Jahr);
//        FileDate := StrTODate(Format('%d.%d.%d', [Filedatum.Tag, Filedatum.Monat, FileDatum.Jahr]));

        if Date > FileDate then Result := vfsOlder;
        if Date <= FileDate then result := vfsAktuell;

     end else Result := vfsNoFile;
 end;

Ich hab mal hingesehen und bemerkt, dass I erst den Wert 7 hat, danach den Wert 6... bis 1.
Wenn ich die mit "->" gekennzeichnete zeile einfüge, hat I erst den Wert 0, dann 1... bis 6.

Wie issn das wieder möglich?
*heul und verzweifel

[Muetze1]

Moin!

1. Was stört dich daran? Es wird doch nix von der Funktionalität verändert, d.h. es kommt immernoch das gleiche raus, egal wie rum er zählt.
2. Die Lösung ist die Optimierung die Delphi beim compilieren noch mitmacht und dadurch kann es sehr gut mal sein, dass er solche Schleifen intern anders aufbaut bzw. die Zählvariable mal rückwärts läuft...
3. Durch die Optimierung läuft die Schleife rückwärts (ist wohl besserer Code) und das nur so lange, wie i selber nicht ausgegeben / weiter verarbeitet wird und somit egal ist. Daher auch die Änderung der Zählrichtung beim einkommentieren...

MfG
Muetze1

[F.W.]

Hmmm, klingt logisch, aber verändert er dann auch das Array? Denn das hat ja [0..6] und die Variable läuft (wenn auch intern) von ->7<- runter.

[SubData]

Also mich würde es schon stören, wenn ich ne Schleife erstelle, die erst vorwärts und dann rückwärts läuft...
Ich zweifel irgendwie daran, dass das wirklich sinnvoll ist. Bitte um genauere Erläuterung was daran Sinn machen soll

[roderich]

Zitat:

Also mich würde es schon stören, wenn ich ne Schleife erstelle, die erst vorwärts und dann rückwärts läuft...
Ich zweifel irgendwie daran, dass das wirklich sinnvoll ist. Bitte um genauere Erläuterung was daran Sinn machen soll

das hat Muetze1 doch eigentlich erklärt, daß die Optimierung dafür verantwortlich ist.
Wie erwähnt wird durch die Optimierung die Schleifenvariable dann in umgekehrter Reihenfolge abgearbeitet, wenn dadurch die Funktionalität identisch bleibt. Das Herunterzählen einer Schleifenvariable erzeugt -soviel ich weiß- einen Assembler-Code mit einer Anweisung weniger pro Schritt.

Da durch die Optimierung der Gewinn in Performance und executable-Größe minimal ist, während auf der anderen Seite das Debuggen verwirrend wird, schalte ich die Optimierung grundsätzlich ab bzw. erst ein für endgültige Software-Releases.

Roderich

[Muetze1]

Moin!

Der Sinn liegt im Endeffekt wirklich darin, das der Code schneller abgearbeitet wird von den CPU's. Da kommt es dann darauf an, das nicht so viele Speicherzugriffe auf einmal auf unterschiedliche Stellen vorkommen, das Schleifen schnell abgearbeitet werden können ohne gross noch dort auf Speicher zu zu greifen, es kommt darauf an, das der Code bestenfalls parallel in den Pipelines des Prozessors verarbeitet werden kann, dass die Sprungvorhersage (Jump Prediction) des Prozessors eine hohe Trefferquote hat, das das Data Prefetching eine hohe Trefferquote hat und frühzeitig Daten holen kann, das es meist die gleichen Speicherstellen sind auf die zugegriffen wird, damit der Cache seine Wirkung hat, etc.

Deshalb die Optimierung. Es ändert sich doch vom reinen Code nix - es ist doch nix gross anders. Auch wenn intern mit 7 bis 1 gezählt wird greift er ordentlich auf das Array zu - dafür sorgt er schon. Ich könnte mir in deinem Fall auch sowas vorstellen, dass er einfach eine Adresse auf das erste Element im Array hat und bei jedem Zugriff entweder automatisch (lodsd) oder selber die Adresse erhöht um auf das nächste Element zu zu greifen mit dem nächsten Durchlauf. Und dadurch wird die Schleifenvariable nur noch für die Anzahl der Durchläufe benötigt und nicht mehr zum Zugriff. Genausogut ist es bei Assembler günstiger ein dec ecx und ein jz @@ zu machen als ein Loop Befehl, etc. Das geht aber nun auch zu sehr ins Detail - zumindest kann ich nix sehen was gegen diese Optimierung spricht. Hier äussert sich das durch die falsche Zählweise, beim anderen male ist mal wieder eine Variable nicht debugbar, weil sie weg-optimiert wurde. Letzteres stört hier die wenigstens noch, aber bei einer Schleife haben alle Angst das der Compiler Müll macht (mein Gefühl hier nach den Postings).

MfG
Muetze1

[F.W.]

@Muetze: Meine Fresse ! Ein bisschen mehr, als ein viertel klang zwar wie chinesisch, aber alles in allem bin ich jetzt beruhigt.

Es war auch mehr die Sorge darum, weil in dem Programmteil, in dem das steckte, estwas nicht funktioniert hat.
Aber jetzt funktioniert's!!

Weil ichs nochmal geschrieben habe

Naja, aber auf 'ne andere Weise. Aber Das ich sowas mal erfahre ist gut, macht der Compiler dabei auch manchmal Fehler? So einmal in 1000 Compilierungen?