Hallo,

ich habe da einen Fehler in Delphi und weiß nicht einmal wieso! Schaut euch mal das Bild im Anhang an. Dort habe ich eine Prozedur gepostet, die Einträge in eine ListView schreibt. Laut dem Code würde das ganze ja auch funktioniert, nur jetzt stellt Delphi was "perverses" mit der For-Schleife an, was ich nicht wirklich nachvollziehen kann.

Laut For-Schleife sollte i bei 0 beginnen und bei 5 aufhören (=Länge des Array minus 1) - Nur beginnt die ganz for-Schleife bei 6 bin ich zu blöd, hab ich einen Fehler drin oder macht das nur mein PC so?

PS: Ich hatte das Problem schon einmal, das war aber damals bei Delphi 5. Konnte es damals nur lösen, in dem ich aus der For-Schleife eine While-Schleife machte, was ich aber nicht will. Das muss doch auch anders gehen!

mfg
shark

Das hatten wir schon ein paarmal, das ist Optimierung, die der Compiler automatisch macht.
Es geht einfach schneller runterzuzählen, als rauf.

Hallo Armin,

Benjamin hat es ja schon kurz beschrieben. Die ausführliche Erklärung findest Du u.a. hier.

Gruß Hawkeye

Nun ja, die Optimierung ist ja eine Sache, aber die wuerde dann trotzdem nur von 5 auf 0 runterzaehlen, und nicht von 6 abwaerts

Greetz
alcaeus

ich denke, dass das ganze wohl nichts mit der
Optimierung zu tun haben sollte.
Wenn der Compiler schon optimiert, dann kann es aber nicht sein
das die Laufvariable einen Wert annimmt der nicht sein darf.

In diesem Fall 6; i kann bzw. sollte doch nur einen Wert von 0 bis max 5 haben.
Tritt Dein Problem auch dann auf wenn Du z.B.
die Prozedure so anpasst, dass Du eine Const max definierst
und das Array NavItems : array[0..max] of array[0..1] of string ...
so definierst.

Die for-Schleife kann dann auch von 0 bis max laufen.
Wird dann immernoch falsch "optimiert"?

Mag es sein, dass length nicht mit dem 2 dimensionalem Array zurechtkommt.

Aus der Hilfe: length - Returns the number of characters in a string or elements in an array.
Und Dein Array hat 6 * 2 Elemente.

Grüße
Klaus


[edit] Text ergänzt [/edit]

Rückwärtszählen ist zwar grundsätzlich eine legitime Optimierungsmöglichkeit, aber hier scheint Delphi nicht nur übers Ziel hinauszuschiessen, sondern auch völig durcheinander zu kommen, oder ist das ein verspäteter Aprilscherz . Und wenn ja, von wem?

Um es genau zu sagen: Delphi optimiert hier den Code kaputt! Wenn s.h.a.r.k hier den verbindlichen Ablaufplan eines Hausbaus in eine Listview schreiben würde (Erst Keller, dann Boden, Wände, 1.Stock ... und zum Schluss das Dach), dann würde Delphi daraus eine ziemlich schwer zu realisierende Arbeitsabfolge generieren; Wer kann schon beim Häuslebau mit dem Dach anfangen...?

Für mich eindeutig ein Fall für Borland bzw. den Delphi-Bug-Report hier im Forum.

PS: D6E funktioniert (natürlich)

Es sind 6 Elemente, 6 mal Dekrementieren führt zum Wert 0, und den Test auf 0 kann man mit einem Assemblerbefehl durchführen.

//Edit: wenn die Laufvariable noch an anderen Stellen benutzt wird, findet keine Optimierung statt.

Gruß Hawkeye

afair laeufts intern so ab:

schleifenanfang:
i := 6
//inhalt der schleife
dec(i)
wenn i <> 0 gehe zu schleifenanfang

oder anders ausgedrueckt:
Folgendermassen muss er bei 6 anfangen und zaehlt bis 1 runter. wenn er bei 0 ankommt springt er raus.
Was das problem ist ist, dass er nicht merkt, dass die Zaehlvariable verwendet wird, denn normalerweise duerfte dann diese Optimierungsmoeglichkeit nicht mehr greifen.

[Add]
Als Problemloesung duerfte dann ein Ausschalten der Optimierung fuer diese Methode reichen, zumindest theoretisch.
[/Add]


greetz
Mike

Du gehst von der falschen Voraussetzung aus das die Tooltips immer korrekt sind.
Das ist insbesondere bei einem Programm mit aktivierter Optimierung nicht der Fall.

Tja, der Compiler ist doch etwas schlauer.
Ich kann zwar keinen Funken Assembler, aber zur Analyse dieses Codes hat es gerade noch gereicht (sofern es überhaupt stimmt ):
Auch hier beginnt i mit 6. Der Witz ist aber, dass i für den Arrayzugriff überhaupt nicht benutzt wird. Vor Schleifenbeginn wird @bla in EBX gespeichert und mit jedem Durchgang um 4 erhöht, der Compiler kann also immer noch optimieren, wie JasonDX es erklärt hat. Gleiches wird wohl bei shark passiert sein, da dort ebenfalls nur auf ein Array zugegriffen wird.

So etwas kommt eben davon, wenn man auf die Idee kommt, mit Optimierungen zu debuggen .