For xx In xxx Schleife rückwärts?

[jaenicke]

Zitat von Stevie:

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.

Definiert ist dieses Verhalten für Arrays:
http://docwiki.embarcadero.com/RADSt...nd_Anweisungen

Zitat:

Array-Ausdrücke können sich auf ein- oder mehrdimensionale Arrays, Arrays mit fester Länge oder dynamische Arrays beziehen. Das Array wird in aufsteigender Reihenfolge durchlaufen, beginnend mit der unteren Array-Grenze bis zur Array-Größe minus eins.

Trotzdem passt die Syntax nicht dazu das vorauszusetzen. Das ist genauso unsauber wie bei AnsiStrings die Länge als Größe in Byte anzunehmen oder die Größe eines Pointers als Größe eines Integers anzunehmen oder...
Schlicht weil es absolut keinen Sinn macht, wenn man auf bestimmte Indizes zugreifen will (eine bestimmte Reihenfolge eben) diese nicht zu benutzen...

[Panthrax]

Delphi-Quellcode:

type
  IEnumerable<T> = interface(IEnumerable)
    ///   <summary>
    ///     Inverts the order of the elements in a sequence.
    ///   </summary>
    function Reversed: IEnumerable<T>;
  end;

Quelle: Spring.Collections.pas:250

Delphi-Quellcode:

program Project1;

{$AppType Console}

{$R *.res}

uses
  System.SysUtils,
  Spring.Collections,
  Spring.Collections.Lists;

procedure Run;
type
  T = String;
var
  List: IList<T>;
  Item: T;
begin
  List := TList<T>.Create;
  List.AddRange(['Eins.', 'Zwei.', 'Drei.', 'Vier.']);
  for Item in List.Reversed do
    WriteLn(Item);
end;

begin
  try
    Run;
  except
    on E: Exception do
      WriteLn(E.ClassName + ': ' + E.Message);
  end;

  if DebugHook <> 0 then
    ReadLn;
end.

Ausgabe:

Code:

Vier.
Drei.
Zwei.
Eins.

[Medium]

Dass etwas geht heisst nicht gleich, dass es auch gut ist. Dass andere dieses etwas gemacht haben ebensowenig, da können jetzt Beispiele noch und nöcher kommen.

Man Verschleiert die Abhängigkeit von einer definierten Reihenfolge durch die Nutzung einer Operation auf einer prinzipiell unsortierten Menge. Dass sie es in der Praxis oftmals dennoch ist, ist nicht Bestandteil des Vorganges, und muss von keiner Implementierung garantiert werden, bzw. kann es in unterschiedlichen Implementierungen unterschiedlich gehandhabt werden. Und allein das würde mich immer wieder dazu motivieren in diesen Fällen for..to zu nutzen, zumal es erheblich besser dokumentiert. Mehr als warnen kann man leider nicht.

[jfheins]

Oder noch besser: Man stelle sich einen zukünftigen Compiler vor, der merkt dass innerhalb der for-in Schleife keine Seiteneffekte auftreten. Und *wuppdi* werden alle 30 Iterationen gleichzeitig ausgeführt. (Bis der Delphi-Compiler das kann habe wir bestimmt 32-Kern CPUs in Laptops) Die Reihenfolge wäre dann nicht-deterministisch und hinge vom Scheduler ab.

Genial, wa?

[jaenicke]

Das würde ich jetzt nicht einmal als zu futuristisch ansehen, denn mit LLVM als Backend muss das ja nicht einmal der Delphi Compiler machen, sondern könnte es dort implementiert werden und einfach genutzt werden. Insofern könnte so etwas schneller kommen als man denkt.