Kurioser Compiler-Hinweis - logisch nicht nachvollziehbar

[Muetze1]

Hmm, das mit dem Umkopieren in einen anderen Array Typ habe ich wohl nicht so ganz mitgeschnitten. Das habe ich nicht rauslesen können. Nun gut - wie gesagt, ich nehme meine erste Aussage von vorhin zurück.

[negaH]

Wenn High(DynArray=mil) < 0 ist und Index ein unsigned Typ ist

if Integer <= Word then ?

Der Compiler hat mit seiner Warnung absolut Recht.

Davon mal abgesehen empfinde ich die Schreibweise deiner IF Abfrage verwirrend, warum nich so

Delphi-Quellcode:

 
if (Index >= Low(Array)) and (Index <= High(Array)) then

Mag daran liegen das man sich an einer der Logiken gewöhnt hat.
Wie gesagt, entweder Index als Integer deklarieren oder dann so

Delphi-Quellcode:

if (High(Array) >= 0) and (Index <= High(Array)) and ... then

das beseitigt zwar nicht die Warnung, aber besetigt den Fehler der entstehen könnte wenn man diese Warnung ignoriert.
Davon abgesehen reicht der Index = type Word nicht aus um den möglichen Bereich den Low() und High() zurückgeben können.
Und da Integer 32Bit sind und Word nur 16 Bit wird ein 32Bit Wert auf einer 32 Bit CPU schneller ausgeführt. Mit 16 Bit Berechnungen auf heutigen 32 Bit CPUs bremst man diese CPU aus.

Gruß Hagen

[negaH]

0-basierter Index ist natürlich falsch, 0-basierter Offset wäre richtiger. Index ist absolut, Offset ist relativ.

Low(DynArray=nil) liefert 0 statt wie bei High(DynArray=nil) = -1, dafür gibt es einen Grund.

Die Abfrage

Delphi-Quellcode:

if (Index >= Low(Array)) and (Index <= High(Array)) then

ist eine Standardabfrage. Wenn High(DynArray=nil) = -1 ist und Index ebenfalls -1 wäre dann verhindert Low(DynArray)=0 das diese Abfrage zutrifft. Man kann also implizit mit dieser Abfrage auch den Index begrenzen, er kann wenn diese Abfrage TRUE liedert niemals < 0 sein, obwohl eben High(DynArray) -1 sein kann.


Gruß Hagen

[Muetze1]

Zitat:

Zitat von negaH

Wenn High(DynArray=mil) < 0 ist und Index ein unsigned Typ ist

if Integer <= Word then ?

Aber liefert nicht high() seinen definierten (auch wenn es Compilermagic ist) Rückgabetyp zurück? Also würde er doch immer -1 liefern können. Oder passt er den Typ dann durch die Compilermagic an, dass er immer den Typ zurück gibt mit dem er vergleicht? Aber ich denke mal, da habe ich wieder was falsch verstanden.

Zitat:

Zitat von negaH

Low(DynArray=nil) liefert 0 statt wie bei High(DynArray=nil) = -1, dafür gibt es einen Grund.

Anderes schönes Beispiel dazu wäre eine For Schleife:

Delphi-Quellcode:

for i := low() to high() do

Da wird die For Schleife niemals ausgeführt, wenn der Endwert vor dem Anfangswert liegt. Somit darf High() niemals 0 liefern bei array = nil und auch darf low() bei array = nil niemals -1 liefern, weil sonst würde einmal entweder ein Durchlauf mit 0 durchgeführt und im zweiten genannten Fall ein Durchlauf mit -1.

Siehe auch die üblichen Listenschleifen (handgemacht, also kein For-In-Do):

Delphi-Quellcode:

for i := 0 to pred(count) do

bzw. alternativ:

Delphi-Quellcode:

for i := 0 to count-1 do

.

Nur mal so als Ergänzung...

[negaH]

Also ich kenne es nur so das High() auch einen negativen Wert liefern kann und somit das Resulat von High() ein signed Datentyp sein muß. Der Vergleich eines unsigned, und Index wurde als Word deklariert, mit einen signed geht nie ganz auf.


High() ist definiert als Count() -1, wenn Count() == 0 ist muß High() -1 sein.

Delphi-Quellcode:

for i := 0 to count-1 do

damit das immer funktioniert, auch bei Count == 0 muß demzufloge I ein signed Datentyp sein.

Gruß Hagen

[Muetze1]

Zitat:

Zitat von negaH

Delphi-Quellcode:

for i := 0 to count-1 do

damit das immer funktioniert, auch bei Count == 0 muß demzufloge I ein signed Datentyp sein.

Wieso? Es würde doch vollkommen reichen wenn Count signed ist. Damit kann das -1 berechnet werden und die Schleife wird nicht durchlaufen bei Count = 0. Eine Zuweisung von -1 an i erfolgt doch niemals.

Von daher die Frage: Würde es nicht vollkommen reichen das Count signed muss, aber i signed sein kann?

Ist erstmal nur eine theoretische Überlegung (also nicht ausprobiert)...

[negaH]

naja die Frage ist berechtigt der Compiler müsste dann folgenden Pseudocode erzeugen

Delphi-Quellcode:

if High() >= 0 then
  for I := 0 to High() do

ich denke aber das er das so nicht implementiert.

In D5 habe ich folgende Loop getestet

Delphi-Quellcode:

var
  I: Cardinal;
  A: array of Byte;
begin
  A := nil;
  for I := Low(A) to High(A) do
    Write('#');
end;

Wie erwartet läuft die Schleife durch, nicht erwartet habe ich das der Compiler keinerlei Warnungen bringt.

Gruß Hagen

[Muetze1]

Zitat:

Zitat von negaH

Wie erwartet läuft die Schleife durch, ...

Hmm, somit implementiert es doch so, dass er den Rückgabewert von High() auf den Typ der Schleifenvariable legt und dabei wohl nicht ordentlich umrechnet (und entsprechend eine Warnung generiert bzw. einen ERangeCheckError, wenn -1 rauskommt) sondern anscheinend hart type-casted. Und genau das hatte ich vorhin noch so im Hinterkopf und von daher die vorherige Frage, ob er den Typ der Compiler-Magic High()-Funktion auf den jeweiligen Typ anpasst.

Zitat:

Zitat von negaH

... nicht erwartet habe ich das der Compiler keinerlei Warnungen bringt.

Das ist mir leider schon öfters aufgefallen bzw. sogar auf die Füsse gefallen...

[negaH]

ne der rechnet garnichts um, Cardinal(-1) == 0xFFFFFFFF, die Schleife läuft bis 2^32-1 durch. Das ist defakto ein Fehler des Compilers. Ich habs erstmal nur mit D5 getestet, aber eine Warnung wäre das mindeste.

Gruß Hagen