tlist. get "überschreiben", Fehlermeldung verhindern

[DrUArn]

Hi,
@Zacherl: ist richtig, manchmal sind die Exceptions gut, aber in meinem Falle könnten sie den Ablauf andauernd unterbrechen. So prüfe ich, ob der Zugriff auf List erlaubt ist, wenn ja, kann der User auf den Eintrag aus get zugreifen, sonst ist Ergebnis nil.

Zum zweiten Teil Deiner Antwort: Habe ich so geschrieben, weils in Tlist.get auch so steht (Unit Classes). Warum das die Delphi-Entwickler so geschrieben haben , weiß ich auch nicht.

Und zu meiner Frage zu Index <0: kommt auch die gleiche Fehlermeldung (...überschreitet Maximum).

Danke, Gruß Uwe

[Zacherl]

Achso, jetzt verstehe ich, warum dort nach Cardinal gecasted wird. Vorzeichenbehaftete Zahlen, wie z.b. Integer werden intern in der sogenannten Zweierkomplement Darstellung realisiert.

Ganz oberflächlich erklärt (für genauere Infos habe ich den Wikipedia Artikel verlinkt):
Die größte signed Byte Zahl im positiven Bereich ist hierbei die 127, welche binär so aussieht: 0 1 1 1 1 1 1 1.
Analog dazu ist die größte darstellbare Zahl im negativen Bereich allerdings folgende: 1 1 1 1 1 1 1 1.

Grob gesagt ist eine Zahl also negativ, wenn das MSB (most significant bit) = 1 ist.

Unsigned Zahlenwerte, wie beispielsweise Cardinal einer ist, verwenden allerdings NICHT die Zweierkomplement Darstellung. Hierdurch ist es beispielsweise möglich, einen größeren Wertebereich abzudecken.

Habe ich jetzt beispielsweise die negative signed Zahl -1 und caste diese in einen Cardinal, so wird die 1 1 1 1 1 1 1 1 nicht mehr als -1 interpretiert, sondern als 255. Dies macht sich die Funktion zum Prüfen der Indizes zu Nutzen.
Cardinal(Index) ist somit bei negativen Zahlen auf jeden Fall größer als Cardinal(Count).

[Medium]

Vorsicht mit dem in Operator: Rechts davon wird eine Menge erstellt, und Mengentypen können in Delphi maximal 256 (oder 255, grad unsicher) Elemente beinhalten.

Davon ab wäre es, auch wenn ich den Nerv-Faktor verstehen kann, dennoch erheblich sauberer die Ursache für "Griffe ins Klo" zu beheben. Das mag im Einzelfall aufwändig erscheinen, man gewinnt aber zumindest zwei sehr wichtige Dinge: Robustheit und Les- bzw. Wartbarkeit, da einem diese Fehlerquelle dann auch nie an anderen potenziellen (auch künftigen) Stellen in die Suppe spucken wird. Nil zurück liefern ist jetzt nicht allzu schlecht, aber den sauberen Weg wärmstens anraten würden vermutlich noch ganz andere als ich