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

[DrUArn]

Hi,
@himitsu: meine obigen Änderungen schlagen wohl alle in das von dir zu vermeidende Kontor.

Diese Gleichsetzung geht tatsächlich.
Ja, meine txyz sind Ableitungen von tobject.

Bis jetzt funktionieren alle Routinen - warum ich mich von tobjectlist wieder abgewendet habe, weiß ich nicht mehr - könnte das aber wieder aufnehmen.

zu Generics - zugegebnermaßen kenne ich diese Schreibweise gar nicht - kann ich auch nicht so schreiben - kommt Fehler tlist<> unbekannt.

Delphi-Quellcode:

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

//bei mir
   TMyList1 = class(TList<Tobj1>)
     function TryGet(idx: Integer; out obj: Ttobj1);
//läßt sich nicht kompilieren

Gruß Uwe

[himitsu]

Du mußt natürlich noch die passende Unit einbinden. :zwinker:

siehe TObjectList = Unit "Generics.Collections"

[DrUArn]

Hi,

ok, mit Generics.collections habe ich mich noch nie beschäftigt.
Bisher habe ich tlist von unit classes verarbeitet!

Generics.collections.tlist kann man den verarbeiteten Zeigertyp festlegen - geht das auch mit Objecten?

Werden diese bei .destroy (.free gibts wohl nicht) mit freigegeben?
In classes.tlist gibt's procedure Notify(Ptr: Pointer; Action: TListNotification); die überschrieben werden kann.

in generics ist das eine Eigenschaft

Fragen über Fragen ...

da Muß ich erst mal 'ne Weile lesen.

Bleibt trotzdem meine Anfrage der abgeleiteten Listen mit abgeleiteten Objekten übrig.

probiert:
tmylist1=class(generics.collections.tobjectlist<tm yobj1>)
end;

nicht erlaubt:
tmylist2=class(generics.collections.tmylist1<tmyob j2>)
end;

man ist also auf den einmalo festgelegten Datentyp festgenagelt - oder?


Gruß Uwe

[himitsu]

Bei TObjectList ist die Notification schon fertig überschrieben.
Man kann im Constructor oder später über OwnsObjects festlegen, ob die enthaltenen Objekte freigegeben werden sollen.

.Free gibt es immer, denn das ist im Basistyp "TObject" deklatiert, von dem jede Klasse erbt.

Destroy besser nicht direkt aufrufen. (das wird dann intern vom Free aufgerufen)



Nun ja, das ist ja grade der Grund/Vorteil ...
- man muß nicht mehr casten und kann sich dabei auch nicht mehr vertun
- wenn man außerhalb keine "bösen" Casts macht, dann kann man ganz einfach davon ausgehn, daß in der Liste immer nur die vorgegebenen Objekte drinnen sind.

Wie bei der restlichen Vererbung gilt auch hier:
- Es können die angegebenen Typen/Klassen/Objekte in diese Listen rein und alle Nachfahren

Eine

Delphi-Quellcode:

TList<xyz>

ist also eine Art

Delphi-Quellcode:

array of xyz

(PS:

Delphi-Quellcode:

TArray<xyz>

), mit ein paar mehr Features/Hilfsfunktionen.

Man kann sich dsa teilweise sehr viel sparen. (versuch mal das Selbe mit einer normalen TList + Record-Pointer + New + Dispose + Notify überschreiben oder mit einer TObjectList + TXyz als Objekt, inkl. Create und Co.)

Delphi-Quellcode:

type
  TXyz = record
    s: string;
    i: Integer;
  end;
var
  Liste: TList<TXyz>;
  X: TXyz;
  Z: Integer;
begin
  Liste := TList<TXyz>.Create;
  try
    X.s := 'abc';
    X.i := 123;
    Liste.Add(X);

    X.s := 'def';
    X.i := 456;
    Liste.Add(X);

    X.s := 'xyz';
    X.i := 789;
    Liste.Add(X);

    for Z := 0 to Liste.Count - 1 do
      WriteLn(X[Z].s, X[Z].i);

    for X in Liste do
      WriteLn(X.s, X.i);
  finally
    Liste.Free;
  end;

Den Namespace in generics.collections.tlist kannst du weglassen. (Delphi weiß anhand des <...>, ob generisch oder nicht).

Tipp: Es gibt ganz viele Turorial-Videos bei Emba, Youtube und Co.

Zitat:

Zitat von DrUArn (Beitrag 1175791)

Bleibt trotzdem meine Anfrage der abgeleiteten Listen mit abgeleiteten Objekten übrig.

Wie überall halt.
In eine Variable TMemo bekommst du ja auch keine TButton rein. (offiziell und ohne böse Casts)

Zitat:

Zitat von DrUArn (Beitrag 1175791)

nicht erlaubt:

Fehlermeldung?

[DrUArn]

Hi,
@himitsu:

Danke, ich habe wohl übersehen, das tlist.free nicht automatisch die eingelagerten Elemente und ihren Speicher löscht (?!)
das macht tobjectlist mit Voreinstellung ownsobjecrts=true.

Deiner Anmerkung:
Wie bei der restlichen Vererbung gilt auch hier:
- Es können die angegebenen Typen/Klassen/Objekte in diese Listen rein und alle Nachfahren

kann ich nicht folgen

Delphi-Quellcode:

tmyobj1=class(tobject)
end;

tmyobj2=class(tmyobj1)
end;

TMyList1 = class(TobjectList<tmyobj1>)
end;

TMyList2 = class(TobjectList<tmyobj2>)
end;

ist nicht erlaubt.

nur so:

Delphi-Quellcode:

TMyList2 = class(TobjectList)
end;

da kann ich sicher tmyobj2 durch add einfügen (du schreibst ja, daß das geht), bekomme aber von get oder items[idx] nur tmyobj1,
würde aber gerne in tmylist2 auch auf tmyobj2 zugreifen, welche ich dort speichern möchte.


habe nun folgendes erfolgreich getestet - bleibt die frage, ob das wieder ein böses casting ist
(erst mal für tobjectlist, dürfte aber genauso für die generischen gehen):

Delphi-Quellcode:

TMyList1 = class(TObjectList) {verwaltet tobj1}
  private
  protected
  public
  function Get(Index: Integer): tmyobj1;virtual;//redefiniert die statische Methode, jetzt wird tobj1 statts pointer zurückgegeben
 end;


function TMyList1.Get(Index: Integer): tmyobj1;
begin
result:=inherited get(index);
//if cardinal(index) < Cardinal(Count) then
//    Result := List^[Index] else result:=nil;
end;

Wenn ich dafür sorge, das nur tobj1 in die Liste reinkommen, kann ich nun ohne Typcasting auf die Einträge zugreifen, muß
aber für alle Lesezugriffe .get benutzen (nicht etwa .items[idx]) - das ist sicher ein Nachteil.

In einer abgheleiteten Liste mit von tmyobj1 abgeleiteten Elementen und überschriebenem .get könnte ich dann
auf die abgeleiteten Elemente zugreifen und auf die schon vorhandenwen Funktionen von der Vorgängerliste.

Oder ist das auch zu sehr um die Ecke gedacht?

in deinem Beispiel
geht das nicht
for Z := 0 to Liste.Count - 1 do
WriteLn(X[Z].s, X[Z].i); x(z).s gibt's nicht

das ist beeindruckend
for X in Liste do
WriteLn(X.s, X.i);
finally

gibt free hier auch die
Einträge selbst frei???
Liste.Free;


Grüße Uwe

[Medium]

Zitat:

Zitat von Zacherl (Beitrag 1175773)

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