tlist. get "überschreiben", Fehlermeldung verhindern

[DrUArn]

Hi,
da mich die Fehlermeldung "Listenindex überschreitet das Maximum" nervt,
möchte ich in einer abgeleiteten tmylist.get "überschreiben"

overwrite nicht mgl., da statisch

Mein Ansatz:

Delphi-Quellcode:

// original
function TList.Get(Index: Integer): Pointer;
begin
  if Cardinal(Index) >= Cardinal(FCount) then
    Error(@SListIndexError, Index);
  Result := FList^[Index];
end;

TMyList_UA = class(TList)
  private

  protected

  public
    function Get(Index: Integer): Pointer;
  published
  end;

function TMyList_UA.Get(Index: Integer): Pointer;
begin
if cardinal(index) in [0 .. count-1] then
    Result := List^[Index] else result:=nil;
end;

//ODER

function TMyList_UA.Get(Index: Integer): Pointer;
begin
  if (cardinal(index)>-1) and (Cardinal(Index) < Cardinal(Count)) then
    Result := List^[Index] else result:=nil;
end;

Beide Funktions-Modelle funktionieren - welches ist besser?
Im tlist.get-Original werden die Indexe <0 nicht geprüft -gibt's da
keinen Fehler?

MfG
Uwe

[Zacherl]

Mal davon abgesehen, dass so eine Exception durchaus sinnvoll ist:
Warum castest du den Index von Integer nach Cardinal? Soweit ich weiß, ist Cardinal ein unsigned Wert, also geht dein Vorzeichen verloren und der Vergleich auf > -1 ist somit immer wahr.

[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 :)

[DrUArn]

Hi,

danke für die Antworten.

@Medium: ok, mit Mengen sollte man wohl doch eher nicht arbeiten in diesem Falle, die 255 könnte auch überschritten werden.
@Zacherl: da hatte ich mich schon mal gewundert, daß bei bit-Operationen im negativen Bereich plötzlich 'ne riesen +-Zahl rauskam - that's it!

@ich: der Grund, warum ich .get überschreiben "wöllte" liegt darin, daß ich in tmylist oft Konstrukte wie diesen gebrauche:

Delphi-Quellcode:

{ursprüngliche Version}
function TMyList.GetIndexWert(aindex:integer): integer;
begin
result:=0;
{1} if Cardinal(Index) < Cardinal(Count) then //das ist jetzt schon aus  tlist adaptiert
{2}  if Get(aindex)<>nil then 
{3}      result:=typumwandlung(get(aindex)).einwert
end;

Wobei ich nun glaube, das {2} nicht nötig ist, wenn ich {1} anwende (doppelt gemoppelt).

bei überschriebenem tmylist.get sieht's so aus

Delphi-Quellcode:

function TMyList.GetIndexWert(aindex:integer): integer;
begin
result:=0;
{2}  if Get(aindex)<>nil then 
{3}      result:=typumwandlung(get(aindex)).einwert
end;

wenn ich euch folge und man tmylist.get nicht überschreiben sollte - wie gesagt, falls ein Fehler im ursprünglichen .get entsteht,kommt die Meldung, die den User "nervt" - dann muß ich an allen Stellen, an denen .get genutzt wird, absichern, daß get nicht daneben greift:

Delphi-Quellcode:

function TMyList.GetIndexWert(aindex:integer): integer;
begin
result:=0;
{1}if Cardinal(Index) < Cardinal(Count)
{3}      result:=typumwandlung(get(aindex)).einwert
end;

Also statt in .get in allen Routinen, wo's kritisch werden könnte
"if Cardinal(Index) < Cardinal(Count)" anwenden?

MfG Uwe

[Zacherl]

Ich würde da persönlich jetzt auch eher wie Medium vorgehen, die Exception nicht überschreiben und stattdessen an jeder "top level" Stelle, bei der irgendwie (indirekt) auf get zugegriffen wird, einen Exception Handler per try .. except implementieren. Dadurch kannst du dann im Zweifelsfalle auch ganz konkrete Fehlermeldugen schmeißen.

[himitsu]

Zitat:

Zitat von DrUArn (Beitrag 1175736)

der Grund, warum ich .get überschreiben "wöllte" liegt darin, daß ich in tmylist oft Konstrukte wie diesen gebrauche:

Dann solltest du dir sowas besser abgewöhnen?

Man könnte sich ein TryGet basteln (ähnlich dem TCriticalSection.TryEnter oder TryStrToInt)

Und bezüglich wilder Typumwandlungen ... da haben die Generics ein paar nette Vorteile.

Delphi-Quellcode:

// statt
if MyList.Get(aindex) <> nil then
  Result := TXyz(MyList.Get(aindex)).einwert;

// lieber
if MyList.TryGet(aindex, X) then
  Result := X.einwert;

// oder das, was du eigentlich wissen/prüfen willst
if MyList.Exists(aindex) then
  Result := MyList.Get(aindex).einwert;

Delphi-Quellcode:

type
  TXyzList = class(TList<TXyz>)
    function TryGet(idx: Integer; out obj: TXyz);
  end;

function TXyzList.TryGet(idx: Integer; out obj: TXyz);
begin
  Result := Cardinal(idx) < Cardinal(Count);
  if Result then
    obj := Get(idx);
end;

var
  X: TXyz;

[DrUArn]

Hi,

@Zacherl: Naja, try except kommt mir immer wie Angst vor übersehenen eigenen Fehlern vor
@Himitsu: Habe ich mir heute ähnlich zusammengebastelt - entspricht wohl deinem Vorschlag .exists(idx)

Delphi-Quellcode:

function TMyList.ValidIndex(aindex: integer): boolean;
begin
 result:= cardinal(aindex)<cardinal(Count) //cardinal <-1 ergibt immer eine Zahl größer als cardinal einer positiven Zahl
end;

Diese "wilden" Typumwandlungen haben mich auch ständig gestört, hatte aber noch keine Idee dazu.
obj :=Get(idx); kann man obj einfach einen pointer aus .get gleichsetzen?
Muß ich erst mal probieren!
OK - habe ich man darf!
Aber: welchen Vorteil bringt {1} obj :=Get(idx) gegenüber {2}txyz(get(idx)?

Ist {1} nicht auch eine Typumwandlung? Man braucht dann noch eine Variable mehr,
könnte in {2} auch mit with txyz(get(idx)) do arbeiten??

Eigentlich habe ich vor, eine weitere Ableitung von tmylist zu schreiben, die eine Ableitung von vobn txyz speichert.
Also:

Delphi-Quellcode:

 tmyobj1= class(tobject)   
  ...  
 end;

tmylist1= class(tlist) //enthält tmyobj1

  function tryget(idx:integer; out:tmyobj1):boolean;virtual;
end;

tmyobj2= class(tmyobj1)
...
end;

tmylist2=class(tmylist1) //enthält tmyobj2
  function tryget(idx:integer; out:tmyobj2):boolean;virtual;
end;

Darf man so was - overload???


Danke an die Diskutanten
Gruß Uwe

[himitsu]

Gleichsetzen nicht (wenn's ginge, dann wäre das allerdings auch wieder ein wilder Cast), aber ich hatte auch nicht die einfache TList, sondern die generische TList<> verwendet.
Jener gibt man den Typ und sie baut diesen bei allen Aufrufen ein, womit dann nicht Pointer, sondern der richtige Type dort steht.


PS: Das "typumwandlung" ist aber nicht zufällig ein Objekt (Klasse) ?
Wenn ja, dann verwende besser die TObjectList, bzw. TObjectList<> .