Kurioser Compiler-Hinweis - logisch nicht nachvollziehbar

[triangulum]

Salü,

Delphi-Quellcode:

if ((low(CurveArray) <= index) and (high(CurveArray) >= index)) then

Der compiler sagt für diese Zeile, "der Vergleich ergibt immer true".

Hmmmm....

Array mit 3 Elementen, dann ist low = 0, high = 2, und index = 6 z.B., dann ist der Ausdruck doch nicht true?!


Fehler vom Kompiler?

[OregonGhost]

Also, erstmal sagt der Compiler nicht "der Ausdruck ergibt immer true", sondern "der Vergleich ergibt immer true". Also ist einer der beiden Vergleiche gemeint. Ist index zufällig unsigned und low kann nicht kleiner als 0 sein (z.B. dynamisches Array)?
0 <= unsigned value ist immer true.

[triangulum]

index ist vom Typ Word und damit in der Tat unsigned.

Dynamisches Array isses auch, also low dann nicht kleiner als 0.

Der Vergleich ist nun dann immer true, wenn low auch nicht größer als 0 sein kann ...

sonst z.B. low =2 und index = 1 ergäbe false

Vermute daher low kann auch nicht größer als 0 sein ....

[Apollonius]

Für dynamische Arrays ist low immer null.

[inherited]

Änder doch mal testweise dein Array in ein statisches mit dem bereich 1 bis irgendwas und compiliere nochmal

[negaH]

Low(Array) gibt dir den 0-basierten Index des 1. Elements zurück.

Was gibt Low() zurück wenn das Array keine Elemente hat, also nil ist ?
Was wird High() zurückgeben in diesem Fall ?

Schon mal in die Hilfe unter Low() und High() geschaut ?

Gruß Hagen

[Muetze1]

Zitat:

Zitat von negaH

Low(Array) gibt dir den 0-basierten Index des 1. Elements zurück.

Ausser bei statischen Arrays welche nicht bei 0 als kleinsten Index definiert wurden. (Array[15..20] -> Low() = 15).

Zitat:

Zitat von negaH

Was gibt Low() zurück wenn das Array keine Elemente hat, also nil ist ?

Immernoch 0 (immernoch bezogen auf dynamische Arrays)

Zitat:

Zitat von negaH

Was wird High() zurückgeben in diesem Fall ?

-1

[Dax]

Zitat:

Zitat von Muetze1

(Array[15..20] -> Low() = 15)

Nur ein Beispiel für Hagens Aussage.

[Muetze1]

Naja, dann sorry, aber "0-basierten Index" hat für mich vom Verständnis soviel bedeutet wie: Immer 0 und dann weiter...

Ergo: erstes Element immer "0" und alle weiteren dann aufsteigend. Seine Aussage stellte sich in meinen AussagenAugen genau anders dar als du es mir nun erklärst.

Aber nun gut, dann nehm ich alles zurück und behaupte das Gegenteil.

[Dax]

Ich lese "0-basierter Index des ersten Elements" als "Index, des ersten Elements, wenn man das Array in ein neues, 0-indiziertes Array kopierte und von dort aus das erste Element des alten Arrays suchte"...

[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