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.

[Medium]

Zitat von 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.

Ich wollte mit meiner Aussage sogar noch einen Schritt weiter: Warum bekommt der Benutzer überhaupt ungültige Auswahlmöglichkeiten angeboten? Die gehören eliminiert! Dann muss auch nichts getryexcepted werden

[DrUArn]

Hi,
nachdem ich noch dies und jenes getestet habe, möchte ich für mich
das Thema abschließen und "Erkenntnisse" zusammenfassen.

1. Ok, mann sollte aus tlist.get die Fehlermeldung nicht rausnehmen
2. Wenn man in tlist Angst vor Fehlgriffen hat, sollte man eine Sicherheitsroutine an kritischen Stellen einrichten alà

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;

3. spezifizierte Listen: Für Speicherung spezieller Datenstrukturen in Listen sind die Generics (tlist<>)bestens geeignet, der Zugriff auf die Elemente ist dann ohne "wilde" Typeumwandlungen möglich - aber

4. Will ich Vererbung sowohl der Elemente als auch der Listen realisieren
komme ich ohne Typumwandlung an irgendeiner Stelle nicht aus:

Delphi-Quellcode:

tmyobj1=class(tobject)
   A:integer;
 end;
 
tmyobj2=class(tmyobj1)
  B:string;
 end;
 
TMyList1withtmyobj1 = class(TobjectList)
    function Get(Index: Integer): tMyobj1;virtual;
    procedure verarbeiteA;
 end;
 
TMyList2withmyobj2 = class(TMyList1withtmyobj1)
   function Get(Index: Integer): tMyobj2;override;
   procedure verarbeiteAundB;
 end; 


function TMyList1withtmyobj1.Get(Index: Integer): tmyobj1;
begin
result:=tmyobj1(inherited get(index));
//result:=inherited get(index); ginge auch bei direkten Naschfahren von tlist
end;

function TMyList2withtmyobj2.Get(Index: Integer): tmyobj2;
begin
result:=tmyobj2(inherited get(index));
end;

TMyList2withmyobj2 soll sowohl .verarbeiteA als auch .verarbeiteAundB können.

TMyList1withmyobj1 währe noch generisch am einfachsten, aber danach nicht mehr.

Darum füge ich eine Methode hinzu, die mir die richtigen Objecte liefert, hier überschreibe ich .get.

Ist das dann 'ne "wilde Typumwandlung"?
Der Übergang von tlist nach tobjectlist geht in der Unit cntnrs ähnliche Wege:

Delphi-Quellcode:

function TObjectList.GetItem(Index: Integer): TObject;
begin
  Result := inherited Items[Index];
end;

function TObjectList.First: TObject;
begin
  Result := TObject(inherited First);
end;

//oder gar items selbst
    property Items[Index: Integer]: TObject read GetItem write SetItem; default;

gerade schnell noch probiert:

property Items[Index: Integer]: TMyobj1 read GetItem write SetItem; default;

procedure SetItem(Index: Integer; AObject: tMyObj1);
function GetItem(Index: Integer): TMyObj1;

.
.
.
function TMyList1withtmyobj1.GetItem(Index: Integer): TMyObj1;
begin
Result := TMyObj1(inherited Items[Index]);
end;

procedure TMyList1withtmyobj1.SetItem(Index: Integer; AObject: TMyObj1);
begin
inherited Items[Index] := AObject;
end;


so braucht man .get nicht zu definieren und kann wie gwohnt auf items zugreifen


Danke allen Diskutanten

Grüße Uwe

[himitsu]

Zitat von DrUArn:

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;