For xx In xxx Schleife rückwärts?

[milos]

Hallo

Ist es möglich in eine For In Schleife rückwärts laufen zu lassen, ohne dass man in der Liste etwas dreht?

MfG

[Union]

Mit

Delphi-Quellcode:

for i := 10 downto 1 do

[jaenicke]

Eine for..in Schleife ist per Definition dafür gedacht, dass man die Elemente in einer beliebigen Reihenfolge durchläuft. Dass sie aufgrund der aktuellen Implementierung eine bestimmte Reihenfolge haben, mag sein, ist aber nicht garantiert.

Deshalb:
Wenn die Reihenfolge wichtig ist, niemals for..in nutzen. Theoretisch kann man das zwar mit einem eigenen Enumerator sicherstellen, aber das ist nicht gerade sauber...
Besser ist es über den Index und for..downto zu gehen und den aktuellen Eintrag selbst ggf. in eine Variable zu speichern um ihn nicht immer wieder aus der Liste abrufen zu müssen.

[milos]

Ok, danke für den Tipp :)

Werde es mit downto lösen. ^^

MfG

[Union]

Dabei ist mir aufgefallen, dass die aktuelle Online-Dokumentation die Delphi-Anweisungen überhaupt nicht beinhaltet. Selbst wenn man die Anweisungen kennt und direkt danach sucht, landet man immer im entsprechenden (und unvollständigen) C++ Teil.

[edit]
http://docwiki.embarcadero.com/RADSt...nd_Anweisungen

Es gibt nur noch eine Riesenseite mit allen Anweisungen.
[/edit]

[himitsu]

Wobei die FOR-IN-Schleife selber nichts mit der Reihenfolge zu tun hat.
Sie läuft einfach nur von vorhne nach hinten alle einträge durch, bis der Enumerator sagt, daß es nichts mehr gibt.

Die Reihenfolge der Daten vom Enumerator sind nicht vorgeschrieben, womit es also kein Problem ist, wenn man sich einen Enumerator erstellt, welcher die Daten in umgekehrter Reihenfolge liefert.

[Stevie]

Zitat:

Zitat von jaenicke (Beitrag 1245162)

Eine for..in Schleife ist per Definition dafür gedacht, dass man die Elemente in einer beliebigen Reihenfolge durchläuft. Dass sie aufgrund der aktuellen Implementierung eine bestimmte Reihenfolge haben, mag sein, ist aber nicht garantiert.

Deshalb:
Wenn die Reihenfolge wichtig ist, niemals for..in nutzen. Theoretisch kann man das zwar mit einem eigenen Enumerator sicherstellen, aber das ist nicht gerade sauber...
Besser ist es über den Index und for..downto zu gehen und den aktuellen Eintrag selbst ggf. in eine Variable zu speichern um ihn nicht immer wieder aus der Liste abrufen zu müssen.

Zitat:

Zitat von himitsu (Beitrag 1245177)

Wobei die FOR-IN-Schleife selber nichts mit der Reihenfolge zu tun hat.
Sie läuft einfach nur von vorhne nach hinten alle einträge durch, bis der Enumerator sagt, daß es nichts mehr gibt.

Die Reihenfolge der Daten vom Enumerator sind nicht vorgeschrieben, womit es also kein Problem ist, wenn man sich einen Enumerator erstellt, welcher die Daten in umgekehrter Reihenfolge liefert.

Das ist nicht ganz korrekt. Für einen Menge Elemente, die einen Index Zugriff bieten, liefert auch ein for-in die Elemente in der gleichen Reihenfolge zurück wie mit einem for-to (nicht for-downto!). Durch die Möglichkeit, selber den Enumerator für eine for-in Schleife zu schreiben, verbietet natürlich keiner, die Elemente in einer komplett anderen Reihenfolge (oder sogar non deterministisch) zurückzuliefern (was aber imho schon an Sabotage grenzt).

[Medium]

Zitat:

Zitat von Stevie (Beitrag 1245201)

(oder sogar non deterministisch [..] was aber imho schon an Sabotage grenzt).

Sehe ich anders. Diese Art der Schleife ist ja gerade darüber definiert, dass sie eine ungeordnete Menge an Elementen iteriert. Würde man sich in einer for..in-Schleife auf ein festgelegtes Iterationsverhalten verlassen, so wäre das extrem schlecht selbstdokumentierender Code. Ein for..to dagegen zeigt direkt eindeutig eine Laufrichtung inkl. Grenzen an. Es hat daher auch durchaus seinen wohl überlegten Sinn, dass beide Konstrukte nebeneinander existieren.
Ein for..in mit einer Abhängigkeit von einer Reihenfolge der Aufzählung würde ich daher sogar als groben Fehler ansehen, da es eine wichtige Sache stark verschleiert.

[Stevie]

Für arrays ist es so implementiert, dass ein for-in einem for-to entspricht.
Für alles andere (wenn ich jetzt grad außer Arrays nix vergessen habe) ist die Implementierung des enumerators, welcher über die GetEnumerator Funktion zurückgeliefert wird, dafür zuständig, welche Reihenfolge angewandt wird.

Da die Delphi Dokumentation ja nicht so ausführlich wie beispielsweise die MSDN ist, kann ich gerade nicht sagen, ob dort für TList<T>, TStrings oder sonstiges, was ein GetEnumerator (also for-in tauglich ist) implementiert, dokumentiert wurde, in welcher Reihenfolge, die Elemente zurückgeliefert werden. In allen mir bekannten Fällen, in denen intern ein Array zur Datenhaltung dient, ist hier das gleiche der Fall, wie oben bereits erwähnt (equivalent zu for-to).

Der primäre Unterschied zwischen einem for-in und einem for-to ist der Indexzugriff, den man bei einem for-in nicht hat bzw nicht benötigt, von daher sind die beiden Konstrukte in keinem Fall komplett redundant.

Ebenfalls kann ich mit einem for-in auch locker über eine endlose Menge iterieren oder über eine, deren Anzahl beim Start noch nicht feststeht.

[Furtbichler]

Zitat:

Zitat von Stevie (Beitrag 1245216)

Für arrays ist es so implementiert, dass ein for-in einem for-to entspricht.

Reiner Zufall. Heute so, morgen anders (Rückwärtszählen geht vielleicht schneller, Speicher ist nicht mehr linear aufgebaut, wer weiß das schon).
Sich darauf zu verlassen, wie etwas implementiert ist, ist -mit Verlaub- ganz großer Käse.

Eigentlich darf man in einer For-In Schleife auch keine Änderungen an der der laufenden Enumeration zugrundeliegenden Datenstruktur vornehmen (auf Gut Deutsch: Die Liste verändern). Aber da ist Delphi wohl nicht so safe.