Forum: Algorithmen, Datenstrukturen und Klassendesign
by jaenicke,
25. Jan 2014
Eben. In der Benutzung ist es aber exakt gleich. Heißt: Man müsste bei der Betrachtung stets nachschauen von was denn die Klasse, die in einem Quelltext benutzt wird, abgeleitet ist, um beurteilen zu können, ob ein Quelltext macht was er soll.
Und das ist ein No-Go in sauberem Quelltext.
Forum: Algorithmen, Datenstrukturen und Klassendesign
by jaenicke,
25. Jan 2014
var
Test: TDictionary<Integer, String>;
Current: TPair<Integer, String>;
begin
Test := TDictionary<Integer, String>.Create;
try
Test.Add(1, 'Eins');
Test.Add(2, 'Zwei');
Test.Add(3, 'Drei');
for Current in Test do
Forum: Algorithmen, Datenstrukturen und Klassendesign
by jaenicke,
25. Jan 2014
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.
Forum: Algorithmen, Datenstrukturen und Klassendesign
by jaenicke,
24. Jan 2014
Definiert ist dieses Verhalten für Arrays:
http://docwiki.embarcadero.com/RADStudio/XE5/de/Deklarationen_und_Anweisungen
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...
Forum: Algorithmen, Datenstrukturen und Klassendesign
by jaenicke,
24. Jan 2014
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...