TObjectList<T> und Comparer

[OlafSt]

Zitat von Der schöne Günther:

Generische Container hin oder her, Sortierer hin oder her:

Dein TPositionComparer leitet sich von TInterfacedObject ab und realisiert ein oder mehrere Interfaces. Solche Instanzen referenzierst du entweder weiterhin über die Klasse, so wie du es mit var TCo: TPositionComparer; getan hast. Oder du verwendest nur Interface-Variablen wie bspw. var myComparer: IComparer<TPosition>) . Dann freust du dich dass es sich nun wie mit Records, Strings oder Arrays verhält: Du machst dir keine Sorgen mehr über die Freigabe und es passiert automatisch.

Aha...TPositionComparer -> Sowohl .Create als auch .Free aufrufen.
IComparer<TPosition>, alles geht von selbst.

Ist das wirklich so simpel ?

Wie sieht das dann in meinem Falle aus ?:

Delphi-Quellcode:

var
   TCo: IComparer<TPosition>;
begin
   FPositions.Sort(TCo);
end;

kann es kaum sein. Woher soll Sort denn wissen, das mein Comparer aufgerufen wird ?

Zitat von Sir Rufo:

Es gibt auch ein TComparer<T>.Construct

Einfach mal in die Doku schauen

Die Doku ist, ebenso wie bei .Sort, einfach nur sensationell unverständlich, wenn man mit Interfaces ein wenig auf Kriegsfuß steht. Außerdem muß da auch noch ein ominöser THasher<T> übergeben werden... Da hab ich erstmal aufgegeben.

[Sir Rufo]

Häh? Beim TComparer<T> ? Wo ist denn da was mit einem Hasher? Das kenne ich nur beim TEqualityComparer<T> und das wird z.B. für ein Dictionary benötigt.

Äuglein auf beim Eierkauf:
TComparer<T> vs. TEqualityComparer<T>

Und so wird der Comparer für TPosition gebaut:

Delphi-Quellcode:

TComparer<TPosition>.Construct(
  function (const L, R: TPosition): integer;
  begin
     if L.TimeStamp < R.TimeStamp then
        Result := -1
     else if L.TimeStamp > R.TimeStamp then
        Result := 1
     else
        Result := 0;
  end );

[OlafSt]

Zitat von Sir Rufo:

Häh? Beim TComparer<T> ? Wo ist denn da was mit einem Hasher? Das kenne ich nur beim TEqualityComparer<T> und das wird z.B. für ein Dictionary benötigt.

Nunja... Ein Druck auf F1, während der Cursor auf einem frisch eingegebenen "TComparer<T>.Construct" steht, führt zum TEqualityComparer. Hab mich auch gefragt, was das wohl mit dem THasher da sein soll, bin aber davon ausgegangen, das der dann wohl optional ist und ein Standard-Hasher genommen wird. Insgesamt ist die OH von XE4 - vorsichtig ausgedrückt - Schrott. Aber einen direkten Weg wie im Visual Studio, wo es direkt ins MSDN geht, ist nicht vorgesehen oder ich habs verkehrt eingestellt. Womit sich die Frage stellt, wo man das einstellt...

Wie dem auch sei, ich hab einiges dazugelernt. So ist

Delphi-Quellcode:

var
   TCo: IComparer<TPosition>;
begin
   FPositions.Sort(TCo);
end;

natürlich Unsinn. Sort weiß ja wirklich nicht, das mein Comparer aufgerufen werden soll, weil TCo=nil. Also gehört da ein TCo:=TPositionComparer.Create; davor. Und genau das ist wohl das verwirrende: Ich muß ein TComparePosition aufrufen, um einen IComparer zu instantiieren.

So langsam raffe ich das Zeug.

[Sir Rufo]

Zitat von OlafSt:

Zitat von Sir Rufo:

Häh? Beim TComparer<T> ? Wo ist denn da was mit einem Hasher? Das kenne ich nur beim TEqualityComparer<T> und das wird z.B. für ein Dictionary benötigt.

Nunja... Ein Druck auf F1, während der Cursor auf einem frisch eingegebenen "TComparer<T>.Construct" steht, führt zum TEqualityComparer. Hab mich auch gefragt, was das wohl mit dem THasher da sein soll, bin aber davon ausgegangen, das der dann wohl optional ist und ein Standard-Hasher genommen wird. Insgesamt ist die OH von XE4 - vorsichtig ausgedrückt - Schrott. Aber einen direkten Weg wie im Visual Studio, wo es direkt ins MSDN geht, ist nicht vorgesehen oder ich habs verkehrt eingestellt. Womit sich die Frage stellt, wo man das einstellt...

Wie dem auch sei, ich hab einiges dazugelernt. So ist

Delphi-Quellcode:

var
   TCo: IComparer<TPosition>;
begin
   FPositions.Sort(TCo);
end;

natürlich Unsinn. Sort weiß ja wirklich nicht, das mein Comparer aufgerufen werden soll, weil TCo=nil. Also gehört da ein TCo:=TPositionComparer.Create; davor. Und genau das ist wohl das verwirrende: Ich muß ein TComparePosition aufrufen, um einen IComparer zu instantiieren.

So langsam raffe ich das Zeug.

Man mag es kaum glauben, aber eine Instanz erzeugt man bei Delphi, wenn man den Konstruktor der Klasse aufruft (es gibt noch andere Wege, aber das ist der klassische Weg).

Und das T davor hat nichts zu sagen, denn es ist einfach nur ein Zeichen, jedes andere Zeichen ist genausogut. Wichtig ist nur, dass ich den exakten Bezeichner der Klasse und nicht die Instanz-Variable benutze.

Delphi-Quellcode:

Foo = class
end;

var
  MyFoo : Foo;
begin
  MyFoo := MyFoo.Create; // kompiliert, ist aber FALSCH
  MyFoo := Foo.Create; 
end;

[DeddyH]

Delphi-Quellcode:

FPositions.Sort(TComparer<TPosition>.Construct(
  function(const Left, Right: TPosition): integer
  begin
    Result := Left.TimeStamp - Right.TimeStamp;
  end
));

[Der schöne Günther]

Richtig- In Sachen Vererbung ist das ja im Endeffekt auch nichts anderes: Du rufst evtl. ein THund.Create() auf und weist das einer TTier -Variable zu. Alles klar soweit in Sachen Interfaces? Das Sortieren mit IComparer<T> und allem ist da schon viel knackiger, finde ich.

Die Doku ist inhaltlich oft falsch, der Kram hinter der F1-Taste nicht zu gebrauchen. Der tatsächliche Inhalt zu System.Generics.Defaults.TComparer.Compare ist aber hier ausnahmsweise sehr brauchbar, finde ich.

Hier mal ein Beispiel mit Integern:

Delphi-Quellcode:

program Project19;

{$APPTYPE CONSOLE}

{$R *.res}

uses System.SysUtils, System.Generics.Collections, System.Generics.Defaults;

type
   /// <summary>
   ///     Vergleicht <c>Integer</c>, jedoch in <b>absteigender</b> Reihenfolge:
   ///    Für diesen Comparer ist <c>5 &gt; 42</c>
   /// </summary>
   TMyReversedIntegerComparer = class(TComparer<Integer>)
      function Compare(const Left, Right: Integer): Integer; override;
   end;

procedure justSortingThings();
var
   myList:            TList<Integer>;
   descendingComparer: IComparer<Integer>;
   item:            Integer;
begin
   myList := TList<Integer>.Create();
   myList.AddRange([5, 42, 5, 99, -37]);

   WriteLn('Normales Sortierverhalten: ');
   myList.Sort();
   for item in myList do WriteLn(item);

   WriteLn(sLineBreak);

   WriteLn('Mein eigenes Sortierverhalten: ');
   descendingComparer := TMyReversedIntegerComparer.Create();
   myList.Sort(descendingComparer);
   for item in myList do WriteLn(item);

   myList.Destroy();
end;


{ TMyReversedIntegerComparer }

function TMyReversedIntegerComparer.Compare(const Left, Right: Integer): Integer;
begin
   Result := -(Left - Right);
end;

begin
  try
   ReportMemoryLeaksOnShutdown := True;
   justSortingThings();
  except
   on E: Exception do
     Writeln(E.ClassName, ': ', E.Message);
  end;
  readln;
end.

Ich persönlich würde es auch mit einer anonymen Methode machen aber im Endeffekt ist es das gleiche.

[OlafSt]

Jetzt kapiere ich auch solchen Code, lieber Günther

Natürlich ist es einfacher und kompakter, eine anonyme Methode zu verwenden. Doch wenn jemand wie ich irgendwann einen Zug verpaßt hat und Interfaces seitdem als großes Mysterium ansieht, dann kapiert man nie die Zusammenhänge.
Darum habe ich den ausführlichen Weg gewählt. Nun weiß ich, das ein Iirgendwas nur eine Schablone darstellt, keine Klasse. Mir ist klargeworden, das ich ein Tirgendwas brauche, damit ich Programmcode hinter das Iirgendwas kriege. Das ich einen Tirgendwas-Konstruktor aufrufen muß, um ein Iirgendwas zu erzeugen. Und das ich am Ende auf ein .Free verzichten kann.

All diese Hintergründe sieht man nicht - und kapiert sie folglich auch nicht - wenn man die Abkürzung nimmt. Wenn dann die OH auch noch in die falsche Richtung schubst bzw. völlig nichtssagend ist, stehst auf verlorenem Posten und es entstehen Kopfschüttler-Threads wie dieser hier

Sokath, seine Augen geöffnet !

[stahli]

Ich finde den Anwendungsfall nicht geeignet um die Sinnhaftigkeit von Interfaces zu diskutieren.

Der Comparer kann als normale Objektinstanz erzeugt werden und wird dann einfach als Interface weiter verabeitet.
Ich bin da etwas drüber gestolpert (http://www.delphipraxis.net/180504-g...nd-contra.html -> #14), weil ich das vermeintliche Objekt wieder freigegeben hatte - was dann zu Problemen führte.
Aber ansonsten ist es ja nicht weiter relevant, dass da ein Interface im Spiel ist.

Wenn Du Dich für Interfaces interessierst solltest Du mal hier suchen. Da gab es viele Diskussionen dazu.
Ich nutze das jetzt auch schon umfangreich.

Die Vorteile sind vor allem:
- Objekte müssen nicht aufgelöst werden
- Klassen müssen nicht veröffentlicht werden
- Objekte können mehere Schnittstellen unterstützen

Das sollte aber besser direkt in Interface-Threads besprochen werden.

[Sir Rufo]

@stahli *hüstel*

Es gibt da so eine Besonderheit mit den Interfaces und der direkten Argumentsübergabe. Das ist auch ein Grund, warum es bei den ganzen Comparer-Erzeugern eine class function Construct gibt und der normale constructor Create versteckt ist.

Nehmen wir mal das Eingangs-Beispiel

Delphi-Quellcode:

var
   TCo: TPositionComparer;
  LPC : IComparer<TPosition>
begin
  FPositions.Add(Result);
  TCo := TPositionComparer.Create;

  // ACHTUNG! TCo ist keine Interface-Variable, 
  // wird aber jetzt als Interface übergeben (Sort Argument)
  // und nach dem Sort ist die Instanz durch die Referenz-Zählung
  // zerstört. In TCo finden wir nur noch einen nutzlosen Referenz-Zeiger

  FPositions.Sort( TCo );
  FPositions.Sort( TCo ); // hier rummst es jetzt

  // besser so:

  LPC := TPositionComparer.Create;
  FPositions.Sort( LPC );
  FPositions.Sort( LPC ); // alles ok, denn LPC ist eine Interface-Variable

  // jetzt das Beste zum Schluss

  FPositions.Sort( TPositionComparer.Create );
  FPositions.Sort( TPositionComparer.Create ); // alles ok, alles funktioniert

  // wirklich alles? NEIN, wir haben ein Speicherleck produziert
end;

Bei der direkten Argumentsübergabe der Referenz, wird der Referenz-Zähler nicht erhöht, darum auch nicht verringert, dadurch wird kein _AddRef und kein _Release aufgerufen, und dadurch wird die Instanz nicht freigegeben.

[stahli]

Ja, ok, das ist schon i.O.

Ich hatte den Eingangspost so verstanden, dass er sich (Anmerkung der Redaktion: "jetzt endlich mal richtig") mit "Interfaces auseinandersetzen" will.

Das Beispiel zeigt aber erst mal nur, wie man den Comparer benutzt.
Hier würde ich noch nicht ableiten, wozu Interfaces gut sind.

Ich wollte nur hinweisen, dass es gute Gründe für Interfaces gibt, die auch schon umfangreich diskutiert wurden (ich hatte vor einiger Zeit auch schon einiges dazu zusammen gesucht) und dass sich diese aus dem Bespiel noch nicht erkennen lassen.