Sortierte TObjectList - Einträge richtig einfügen

[Benmik]

Auf der anderen Seite liefert BinarySearch so ziemlich genau das, was ich will:

Zitat:

The method returns true if it finds the element and false otherwise. If found, Index contains the zero-based index of Item. If not found, Index contains the index of the first entry larger than Item.

Perfekt wär's, wenn das auch noch wär (was es aber nicht ist):

Zitat:

If there is more than one element in the list equal to Item, the index of the first match is returned in Index. This is the index of any of the matching items, not necessarily the first.

Aber sonst ziemlich genau das, was ich nachgebaut habe. Muss doch wohl meine erste generische Liste in Angriff nehmen.

Vielleicht noch eine Idee zu den anderen Fragen?

[stahli]

Gute Entscheidung.
Generische Listen werden Dir hier helfen.

Du musst nur einen TComparer definieren, der Dir kleiner, gleich oder größer zu Deinen Items zurück liefert. Den Rest kannst Du der Binärsuchfunktion überlassen.

Eine Neusortierung musst Du eigentlich gar nicht machen, da Du jeden Eintrag direkt an die passende Stelle einsortieren kannst.
(Im Nachhinein bin ich nur nicht sicher, ob Extract aus meinem Beispiel vorhin die binäre Suche benutzt. Sonst müsste man eben explizit binär suchen und den Eintrag an dem gefundenen Index entfernen.)


Für unterschiedliche Sortierungen (nach Eigenschaft A oder B) habe ich keine Lösung parat.
Man könnte den Comparer unterschiedlich steuern (case ... of) und müsste die Liste dann aber bei einer Umschaltung komplett umsortieren.
Oder man verwaltet mehrere Listen mit Objektreferenzen und sortiert die binär verschieden. Muss man halt immer alle synchron halten und Einträge immer in allen einfügen bzw. entfernen.
Die beste Lösung hängt sicher vom Einzelfall ab. Wenn man sich eine Factory baut, die das Einfügen und Entfernen zentral übernimmt, kann die das synchronisieren der Listen natürlich schön automatisieren.

Ganz nützlich kann auch ein Dictionary sein, was idR. noch schneller als eine binäre Liste funktioniert.


Zu Listentypen will ich gleich nochmal auf meinen kürzlichen Link zu Video2Brain verweisen ... hierin: http://www.delphipraxis.net/1308861-post28.html
Die Trainerin fasst das m.E. ganz gut zusammen.

[Sir Rufo]

Delphi-Quellcode:

uses
  Generics.Collections,
  Generics.Defaults;

type
  TZiel = class(TObject)
    WERT1 : Word;
    WERT2 : Word;
    WERT3 : String;
    WERT4 : String;
    WERT5 : Cardinal;
    WERT6 : Int64;
    WERT7 : Int64;
  end;

  TZielListe = class( TObjectList<TZiel> )
  private
    function Compare( const L,R: TZiel) : Integer;
  public
    constructor Create( OwnsObjects: Boolean = true );
  end;

function TZielListe.Compare( const L,R: TZiel) : Integer;
begin
  Result := TComparer<string>.Default.Compare( L.Wert3, R.Wert3 );
end;

constructor TZielListe.Create( OwnsObjects: Boolean );
begin
  inherited Create( TComparer<TZiel>.Construct( Compare ), OwnsObjects );
end;

[Benmik]

Danke euch beiden! Sensationell.

Schließe mich dem an: Kaum macht man's richtig - schon funktioniert's.

[stahli]

Dann wird das ja nochmal einfacher.
(Wobei das bezüglich Lesbarkeit für normale Menschen schon etwas gewöhnungsbedürftig ist. )

Könnte man im Compare dann auch per Case dynamisch die Sortierung umstellen? Und wenn ja, müsste die komplette Liste in dem Moment auch neu durchsortiert werden - richtig?

[Sir Rufo]

Die Liste wird mit dem Comparer sortiert, wenn man TList<T>.Sort aufruft.

Will ich eine andere Sortierung haben, dann mit TList<T>.Sort( AComparer: IComparer<T> ) aufrufen.

Der Comparer, den man im Konstruktor mit angibt, sorgt nicht nur für die (Standard-)Sortierung, sondern damit wird auch die Gleichheit der Elemente ermittelt.

Delphi-Quellcode:

var
  Ziel1, Ziel2, Ziel3 : TZiel;
  ZielList : TZielList;

Ziel1 := TZiel.Create; // erste Instenz
Ziel1.Wert3 := 'Foo';
Ziel2 := TZiel.Create; // zweite Instanz
Ziel2.Wert3 := 'Foo';

// Ziel1 und Ziel2 sind unterschiedliche Instanzen

ZielList := TZielList.Create;

ZielList.Add( Ziel1 );
ZielList.IndexOf( Ziel1 ); // wie zu erwarten erhält man 0
ZielList.IndexOf( Ziel2 ); // und hier? auch eine 0!!!

ZielList.Contains( Ziel1 ); // liefert true
ZielList.Contains( Ziel2 ); // liefert auch true

Ziel3 := ZielList.Extract( Ziel2 ); // welche Referenz ist jetzt in Ziel3? Ziel1, Ziel2, nil?

if Ziel3 = nil then
  ShowMessage('Ich bin leer');
if Ziel3 = Ziel2 then
  ShowMessage( 'Ich bin Ziel2' );
if Ziel3 = Ziel1 then
  ShowMessage( 'Ich bin Ziel1' );

[Benmik]

Und das am Freitagnachmittag!

Was ich - unter anderem - nicht verstehe, ist, woher der Comparer weiß, dass der beim Vergleich der Objekte "TZiel" Ziel.Wert3 vergleichen muss / soll. Ich habe mich nämlich auch schon gefragt, wie man BinarySearch verwendet, wenn man doch gar nicht die Objekte, sondern deren einzelne Werte finden will. Bei stackoverflow habe ich eine Konstruktion mit Dummy (und auch noch mit einer anonymen Methode, heute bleibt mir nichts erspart) gefunden:

Delphi-Quellcode:

function SearchList(Wert:string; Liste:TZielListe): Integer;
var Dummy : TZiel;
begin
  if not Liste.BinarySearch(Dummy, Result, TDelegatedComparer<TZiel>.Construct(
      function (const L, R: TZiel): Integer
      begin
        Result := AnsiCompareText(L.Wert3,Wert);
      end)) then
    Result := -1;
end;

Geht das auch anders?

[Sir Rufo]

Du legst doch im Comparer fest, dass mit TZiel.Wert3 verglichen werden soll

Delphi-Quellcode:

function (const L, R: TZiel): Integer
      begin
        Result := AnsiCompareText(L.Wert3,Wert);
      end

[Benmik]

Ja, in dem Dummy-Beispiel. Mit dem Dummy wird das Problem umgangen, dass auf beiden Seiten TZiel erwartet wird, während man aber TZiel.Wert3 gegen einen frei gewählten Wert vergleichen lassen will. Das Beispiel funktioniert ja auch, es ist eben nur eine Krücke. Der Compiler beschwert sich auch, dass Dummy nicht initialisiert worden sei. Daher meine Frage, ob das auch eleganter geht.

Du verwendest auch Ziel.Wert3. Ich vermute, dass die Funktionen IndexOf und Contains alle Werte von Ziel vergleichen, um Gleichheit festzustellen. Die Funktionen würden also negativ ausfallen, wenn beispielsweise Ziel.Wert2 verschieden wäre (so vermute ich).

[Perlsau]

Moin allerseits, habe den Quellcode aus #9 in meinen zu integrieren versucht. Bei mir sieht das dann so aus:

Delphi-Quellcode:

UNIT ServerLogFiles;

INTERFACE

USES
  Windows, Classes, Messages, SysUtils, StrUtils, Generics.Collections, Generics.Defaults, Variants,
  LogFiles; // Klasse TLogFiles

TYPE
  TFileListe = CLASS(Generics.Collections.TObjectList<TLogFiles>)
    PRIVATE
      Function Compare(Item1, Item2 : TLogFiles): Integer;
    PUBLIC
      Constructor Create(OwnsObjects : Boolean = true);
  END;

TYPE
  TServerLogFiles = CLASS

  PRIVATE { Private-Deklarationen }

      FileList : TFileListe;
      ...
  END;

IMPLEMENTATION

{ TFileListe }

Function TFileListe.Compare(Item1, Item2 : TLogFiles): Integer;
begin
  Result := TComparer<String>.Default.Compare(Item1.FileName, Item2.FileName);
end;

Constructor TFileListe.Create(OwnsObjects: Boolean);
begin
 inherited Create(TComparer<TLogFiles>.Construct(Compare), OwnsObjects); // Fehler
end;

{ TSERVERLOGFILES }

...

end.

Beim Compilieren erhalte ich im Constuctor von TFileListe diesen Fehler bei (Compare):
ServerLogFiles.pas(96): E2010 Inkompatible Typen: 'TComparison<LogFiles.TLogFiles>' und 'Procedure of object'

Was mache ich da falsch?