TObjectList<T> und Comparer

[OlafSt]

Hi Freunde,

nun ist es soweit, es gibt kein Entrinnen mehr. Ich muß mich endgültig mit Interfaces auseinandersetzen. Kam ja bisher immer drumherum... Mein Problem und Ziel ist es, eine sortierte generische TObjectList zu bekommen. Folgende, stark gekürzte Klasse:

Delphi-Quellcode:

    TPosition = class(TObject)
    public
      TimeStamp: TDateTime;
    end;

soll in eine TObjectList<TPosition> hinein und die Liste nach TPosition.TimeStamp sortiert werden. Dazu gibt es ja TObjectList<T>.Sort(IComparer<T>). Also habe ich eine Klasse gebastelt, die IComparer implementiert:

Delphi-Quellcode:

    TPositionComparer = class(TInterfacedObject, IComparer<TPosition>)
       function Compare(const Left, Right: TPosition): integer;
    end;

function TPositionComparer.Compare(const Left, Right: TPosition): integer;
var
   RDT, LDT: TDateTime;
begin
     RDT:=Right.Timestamp;
     LDT:=Left.Timestamp;
     if LDT < RDT then
        exit(-1);
     if LDT=RDT then
        exit(0)
     else
        exit(1);
end;

Schön ausführlich, damit wir auch schön debuggen können und so.

Im Einsatz sieht das ganze dann so aus:

Delphi-Quellcode:

var
   TCo: TPositionComparer;
begin
     //Result ist ein TPosition und wird hier zusammengebaut
     //FPositions ist eine TObjectList<TPosition>
     FPositions.Add(Result);
     TCo:=TClientComparer.Create;
     FPositions.Sort(TCo);

Compiliert klaglos. Funktioniert klaglos.

Fragen: Abgesehen davon, das ich auch eine anonyme Methode hätte verwenden können: Ist das überhaupt so richtig aufgebaut ? Außerdem höre ich immer wieder, das man Interfaces nicht wieder freigeben muß. Trifft das auch auf mein TCo, das ich immer wieder neu erzeuge, zu ? Wenn nein, wie muß das dann gemacht werden ?

Danke für die Hilfe !

[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

Delphi-Quellcode:

var TCo: TPositionComparer;

getan hast. Oder du verwendest nur Interface-Variablen wie bspw.

Delphi-Quellcode:

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.

[Stevie]

Oder du übergibst den Comparer direkt beim Liste erstellen, dann kannste Sort auch so aufrufen.

[Sir Rufo]

Es gibt auch ein

Delphi-Quellcode:

TComparer<T>.Construct

;)

Einfach mal in die Doku schauen

[OlafSt]

Zitat:

Zitat von Der schöne Günther (Beitrag 1287931)

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

Delphi-Quellcode:

var TCo: TPositionComparer;

getan hast. Oder du verwendest nur Interface-Variablen wie bspw.

Delphi-Quellcode:

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:

Zitat von Sir Rufo (Beitrag 1287944)

Es gibt auch ein

Delphi-Quellcode:

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

Delphi-Quellcode:

TComparer<T>

? Wo ist denn da was mit einem Hasher? Das kenne ich nur beim

Delphi-Quellcode:

TEqualityComparer<T>

und das wird z.B. für ein Dictionary benötigt.

Äuglein auf beim Eierkauf:

Delphi-Quellcode:

TComparer<T>

vs.

Delphi-Quellcode:

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 );

[DeddyH]

Delphi-Quellcode:

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

[OlafSt]

Zitat:

Zitat von Sir Rufo (Beitrag 1287954)

Häh? Beim

Delphi-Quellcode:

TComparer<T>

? Wo ist denn da was mit einem Hasher? Das kenne ich nur beim

Delphi-Quellcode:

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

Delphi-Quellcode:

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.

[Der schöne Günther]

Richtig- In Sachen Vererbung ist das ja im Endeffekt auch nichts anderes: Du rufst evtl. ein

Delphi-Quellcode:

THund.Create()

auf und weist das einer

Delphi-Quellcode:

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 !

[Sir Rufo]

Zitat:

Zitat von OlafSt (Beitrag 1287962)

Zitat:

Zitat von Sir Rufo (Beitrag 1287954)

Häh? Beim

Delphi-Quellcode:

TComparer<T>

? Wo ist denn da was mit einem Hasher? Das kenne ich nur beim

Delphi-Quellcode:

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

Delphi-Quellcode:

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;

[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

Delphi-Quellcode:

class function Construct

gibt und der normale

Delphi-Quellcode:

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

Delphi-Quellcode:

_AddRef

und kein

Delphi-Quellcode:

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

[OlafSt]

Ich habe mich schon oft an Interfaces versucht, Gerade in C# ist man mit denen ständig beschäftigt. Aber ich verstand nie die Mechaniken, wie man es nun konkret anwendet. Schon gar nicht in Delphi.
Ich habe die Angewohnheit, erstmal zu begreifen, wie "das alles funktioniert". Ideen, wo man das dann einsetzen kann, kommen dann quasi von selbst. Da mir das ganze in Delphi immer ein Rätsel war, habe ich TObjectList<T>.Sort einfach als Aufhänger benutzt um ein für alle mal in den Kopf zu kriegen, wie das läuft.

Aus meiner Sicht hatte .Sort quasi das Pech, dafür herhalten zu müssen. Ich mußte erst selbst erkennen, das man eine Klasse braucht, um ein Interface zu implementieren (ein Fakt, der nie in dieser Form erwähnt wurde oder den ich nie realisiert habe :oops:). Das man dann den Konstruktor so einer Klasse aufruft, ist eigentlich logisch - warum dieser Aufruf aber nun plötzlich einen IComparer ergibt, statt eines TPositionComparer, war mir auch immer ein Rätsel. An das nicht-mehr-freigeben-müssen muß man sich auch erstmal gewöhnen (ich erwische mich ständig dabei, in C# immer wieder Routinen so zu bauen, das ich am Ende alles aufräumen kann :)).

Ganz ehrlich: Ich benutze ganz bestimmt nicht etwas, von dem ich nicht mal weiß, wie ich es instanziert bekomme.

Dieses Problem ist vom Tisch. Der Rest findet dann in den geeigneteren Unterforen statt :thumb:

[Sir Rufo]

Hier mal ein kleines Beispiel mit Interfaces

Wir habe da einen Dienst, der uns einen ganz simplen Text liefert.

Delphi-Quellcode:

unit DatenHoler;

interface

type
  IDatenHoler = interface
    ['{4C5405CE-04AF-43C0-BB06-00C1051C12D8}']
    function HoleDaten: string;
  end;

implementation

end.

Konkret bekommen wir diese Daten per HTTP geliefert und es dauert pro Abfrage eine Sekunde bis wir die Daten bekommen.

Delphi-Quellcode:

unit HttpDatenHoler;

interface

uses
  DatenHoler;

type
  THttpDatenHoler = class( TInterfacedObject, IDatenHoler )
  public
    function HoleDaten: string;
  end;

implementation

uses
  System.SysUtils;

{ THttpDatenHoler }

function THttpDatenHoler.HoleDaten: string;
begin
  Sleep( 1000 );
  Result := 'Hier sind die Daten ' + DateTimeToStr( Now );
end;

end.

Das ganze sieht dann so aus:

Delphi-Quellcode:

procedure BenutzeDatenHoler( ADatenHoler: IDatenHoler );
var
  LIdx: Integer;
begin
  for LIdx := 1 to 10 do
    begin
      Write( DateTimeToStr( Now ), ': ' );
      Writeln( ADatenHoler.HoleDaten );
    end;
end;

procedure Start;
var
  LDatenHoler: IDatenHoler;
begin
  Writeln( 'Direkte Anfrage an den DatenHoler' );
  LDatenHoler := THttpDatenHoler.Create;
  BenutzeDatenHoler( LDatenHoler );
end;

Ist ja ganz witzig, aber irgendwie dauert mir jede Abfrage zu lange, aber in meiner Anwendung merken will ich mir das trotzdem nicht ... egal, wir haben ja gegen ein Interface programmiert und machen einfach mal das hier:

Delphi-Quellcode:

unit CachedDatenHoler;

interface

uses
  DatenHoler;

type
  TCachedDatenHoler = class( TInterfacedObject, IDatenHoler )
  private
    FDatenHoler: IDatenHoler;
    FHasCachedData: Boolean;
    FCachedData: string;
  public
    constructor Create( ADatenHoler: IDatenHoler );
    function HoleDaten: string;
  end;

implementation

{ TCachedDatenHoler }

constructor TCachedDatenHoler.Create( ADatenHoler: IDatenHoler );
begin
  inherited Create;
  FDatenHoler := ADatenHoler;
end;

function TCachedDatenHoler.HoleDaten: string;
begin
  if not FHasCachedData
  then
    begin
      FCachedData := FDatenHoler.HoleDaten;
      FHasCachedData := True;
    end;
  Result := FCachedData;
end;

end.

Und ändern (nur) den Start wie folgt ab:

Delphi-Quellcode:

procedure Start;
var
  LDatenHoler: IDatenHoler;
begin
  Writeln( 'Cache Anfrage an den DatenHoler' );
  LDatenHoler := THttpDatenHoler.Create;
  LDatenHoler := TCachedDatenHolder.Create( LDatenHoler );
  BenutzeDatenHoler( LDatenHoler );
end;

Schon gehts nach der ersten Abfrage ab wie der Wind und meine Anwendung musste ich auch nicht ändern :)

Man beachte, dass der

Delphi-Quellcode:

TCachedDatenHoler

keinerlei Kenntnis von dem

Delphi-Quellcode:

THttpDatenHoler

hat, der eigentlich die Daten besorgt. Da macht ein Interface dann richtig Spass.

[OlafSt]

Sowas in der Art war auch meine erste Idee, nachdem ich das mit dem Konstruktor, der ein Interface liefert, kapiert hatte.

Ich habe hier eine Anwendung, die von den verschiedensten Telematik-Blackboxes Daten empfangen, verarbeiten und in strukturierter Form verfügbar machen muß. Ein simpler Decoder halt.

Dabei senden manche Boxen per UDP, andere per TCP, ein paar Sonderlinge sogar per SMS ;) Das Protokoll, das da gefahren wird, ist jedesmal unterschiedlich, was aber hinten rauskommen muß, muß stets gleichartig sein. Das können GPS-Daten sein, I/O-Port-Daten, GSM-Infos und vieles mehr. Mal nur eines von denen, mal mehrere, mal ein dutzend von dem, ein paar von jenen.

Schreit nach Interfaces, da das wesentliche immer gleich ist: Connect, CanDecode, Decode, FetchResult.

[Sir Rufo]

Damit das auch noch einen Bezug zum Sort findet:

Delphi-Quellcode:

unit ComparerFun;

interface

uses
  System.SysUtils,
  System.Generics.Defaults;

type
  TInverseComparer<T> = class( TInterfacedObject, IComparer<T> )
  private
    FComparer: IComparer<T>;
    function Compare( const Left, Right: T ): Integer;
    constructor Create( AComparer: IComparer<T> );
  public
    class function Construct( AComparer: IComparer<T> ): IComparer<T>;
  end;

  TConsoleLogStringComparer = class( TInterfacedObject, IComparer<string> )
  private
    FComparer: IComparer<string>;
    function Compare( const Left, Right: string ): Integer;
    constructor Create( AComparer: IComparer<string> );
  public
    class function Construct( AComparer: IComparer<string> ): IComparer<string>;
  end;

implementation

{ TInverseComparer<T> }

function TInverseComparer<T>.Compare( const Left, Right: T ): Integer;
begin
  Result := -FComparer.Compare( Left, Right );
end;

class function TInverseComparer<T>.Construct( AComparer: IComparer<T> ): IComparer<T>;
begin
  Result := Self.Create( AComparer );
end;

constructor TInverseComparer<T>.Create( AComparer: IComparer<T> );
begin
  Assert( Assigned( AComparer ) );
  inherited Create;
  FComparer := AComparer;
end;

{ TConsoleLogStringComparer }

function TConsoleLogStringComparer.Compare( const Left, Right: string ): Integer;
begin
  Result := FComparer.Compare( Left, Right );
  WriteLn( Format( 'Compare( "%s", "%s" ) = %d', [Left, Right, Result] ) );
end;

class function TConsoleLogStringComparer.Construct( AComparer: IComparer<string> ): IComparer<string>;
begin
  Result := Self.Create( AComparer );
end;

constructor TConsoleLogStringComparer.Create( AComparer: IComparer<string> );
begin
  Assert( Assigned( AComparer ) ); // Ein simpler Guard
  inherited Create;
  FComparer := AComparer;
end;

end.

Und ein kleines Progrämmle:

Delphi-Quellcode:

program dp_183670;

{$APPTYPE CONSOLE}
{$R *.res}

uses
  System.SysUtils,
  System.Generics.Defaults,
  System.Generics.Collections,
  ComparerFun in 'ComparerFun.pas';

procedure OutputList( const AList: TList<string> );
var
  LItem: string;
begin
  Write( 'Elemente: ' );
  for LItem in AList do
    begin
      Write( LItem, ' ' );
    end;
  Writeln;
end;

procedure SortElements( const AValues: TArray<string>; AComparer: IComparer<string> );
var
  LList: TList<string>;
begin
  LList := TList<string>.Create;
  try
    LList.AddRange( AValues );
    LList.Sort( AComparer );
    OutputList( LList );
  finally
    LList.Free;
  end;
end;

procedure StartSort;
var
  LComparer: IComparer<string>;
  LValues: TArray<string>;
begin
  LValues := ['foo', 'bar', 'foobar', 'barfoo'];

  Writeln( 'Default-Comparer' );
  LComparer := TComparer<string>.Default;
  SortElements( LValues, LComparer );

  Writeln( 'Invers-Default-Comparer' );
  LComparer := TInverseComparer<string>.Construct( LComparer );
  SortElements( LValues, LComparer );

  Writeln( 'ConsoleLog-Invers-Default-Comparer' );
  LComparer := TConsoleLogStringComparer.Construct( LComparer );
  SortElements( LValues, LComparer );

end;

begin
  try
    StartSort;
  except
    on E: Exception do
      Writeln( E.ClassName, ': ', E.Message );
  end;
  ReadLn;

end.

Und man erhält folgende Ausgabe

Code:

Default-Comparer
Elemente: bar barfoo foo foobar

Invers-Default-Comparer
Elemente: foobar foo barfoo bar

ConsoleLog-Invers-Default-Comparer
Compare( "foo", "bar" ) = -4
Compare( "bar", "bar" ) = 0
Compare( "barfoo", "bar" ) = -3
Compare( "foobar", "bar" ) = -4
Compare( "bar", "bar" ) = 0
Compare( "foobar", "bar" ) = -4
Compare( "foo", "barfoo" ) = -4
Compare( "barfoo", "barfoo" ) = 0
Compare( "foobar", "barfoo" ) = -4
Compare( "foo", "foo" ) = 0
Compare( "foobar", "foo" ) = -3
Elemente: foobar foo barfoo bar

[OlafSt]

Eines verstehe ich da nicht: Wozu dient der Parameter AComparer in den class functions/constuctors ?

Wenn ich das recht interpretiere, ist die

Delphi-Quellcode:

class function .Construct

eine Factory. Die weiß also, was da zu erstellen ist - der Parameter AComparer wird dann dem Konstruktor mitgegeben und einfach nur gespeichert.

Führt das nicht dazu, das der konkrete Comparer eine Referenz auf sich selbst hält ? Ist mir schleierhaft, wofür das gut sein soll...

[Sir Rufo]

Es passiert doch das gleiche wie in dem vorherigen Beispiel. Es wird ein Interface gewrappt

[OlafSt]

Dammit, du hast recht... stahli hatte ein paar Posts zuvor einen Link gepostet, wo einem auf witzige Art das Wrapping beigebracht wurde. Hab da das erste mal von Wrapping gehört, ergo noch ein paar Schwierigkeiten, das zu erkennen.
Damit macht jedenfalls die übergebene Referenz einen Sinn (und ist auch unabdingbar).

Wieder was gelernt und gelerntes gleich geübt, hehe.

[stahli]

Ich habe mal zum Thema Interfaces einige Infos zusammengestellt: http://www.delphipraxis.net/183702-i...-factorys.html