Seltsames Verhalten von IndexOf bei sortierter generischer Liste

[Bummi]

Wenn man sich die Implementierung von
function TList<T>.IndexOf(const Value: T): Integer; anschaut ....
Gegf. könntest Du

Delphi-Quellcode:

function( const L, R : TItem ) : Integer
    begin
      Result := L.Value - R.Value;
    end )

erweitern um einen Vergleich von ID wenn Value identisch ist.....

[Furtbichler]

Ich habe den Quellcode nicht, aber falls IndexOf iterativ umgesetzt ist, ist das Verhalten doch vollkommen ok.

Deine Ordnungsfunktion ist nicht vollständig implementiert, d.h. es gilt eben nicht: A != B => f(A) != f(B)

Lösung? => Bummi

Zitat von Sir Rufo:

... fügt man weitere Elemente hinzu, so ist die Liste nicht automatisch sortiert, aber für die Bestimmung des Item-Index wird der Comparer bemüht ...

Wieso erwartest Du, das die Liste automatisch sortiert ist? Das wäre doch performancetechnisch völliger Quark und ist außerdem nicht die Aufgabe einer Liste.

Die Liste ist ein Container für Elemente. Mit der Definition einer Ordnungsrelation ('Comparer') und der Sort-Methode kann eine totale Ordnung hergestellt werden. Nach dem Einfügen eines Elements kann die Ordnung zerstört werden.

Und natürlich muss der Comparer bemüht werden, woher sonst soll die Liste wissen, ob zwei Elemente 'gleich' sind? Das 'gleich' wird ja gerade durch den Comparer definiert.

Was passiert, wenn Du keine Ordnungsrelation angibst? Geht das?

[Sir Rufo]

Zitat von Furtbichler:

Zitat von Sir Rufo:

... fügt man weitere Elemente hinzu, so ist die Liste nicht automatisch sortiert, aber für die Bestimmung des Item-Index wird der Comparer bemüht ...

Wieso erwartest Du, das die Liste automatisch sortiert ist? Das wäre doch performancetechnisch völliger Quark und ist außerdem nicht die Aufgabe einer Liste.

Ich erwarte doch nicht, dass die Liste sich automatisch selber sortiert. Aber ich erwarte eben von einer Liste, dass ich mit IndexOf den Index des Elements in der Liste bekomme, also

Delphi-Quellcode:

MyIndex := 4;
Assert( MyList.IndexOf( MyList[MyIndex] ) = MyIndex );

Den Comparer habe ich jetzt erweitert zu

Delphi-Quellcode:

  LList := TObjectList<TItem>.Create( TComparer<TItem>.Construct(
        function( const L, R : TItem ) : Integer
    begin
      Result := L.Value - R.Value;
      if Result = 0
      then
        Result := Integer( L ) - Integer( R );
    end ) );

bzw. im originalen Code merke ich mir einfach den Index und der Kas ist gegessen.

[Furtbichler]

Zitat von Sir Rufo:

Aber ich erwarte eben von einer Liste, dass ich mit IndexOf den Index des Elements in der Liste bekomme,

Du wusstest nicht, das der 'Comparer' auch für die Definition von 'Gleichheit' verwendet wird.

Ich halte das für einen Designfehler, und ich glaube, Du auch. Denn ein *TComparer* vergleicht nur und wird für das Sortieren verwendet.

In einer TSortedObjectList (wenn es das gäbe), würde IndexOf (weil mit Binärsuche implementiert) allerdings den Comparer verwendetn. Vielleicht wurde das deshalb so umgesetzt.


Nur mal so: Der Comparer definiert eine Ordnung und man muss sich einfach auch überlegen, wann zwei Objekte gleich, d.h. identisch sind.
Identisch bedeutet auch 'austauschbar', und dann reicht die erste Implementierung eben nicht aus.

[BUG]

Zitat von Furtbichler:

Ich halte das für einen Designfehler, und ich glaube, Du auch. Denn ein *TComparer* vergleicht nur und wird für das Sortieren verwendet.

Ich glaube bei Strings würdest du es wieder nicht für einen Designfehler halten
Den Comperator zu verwenden ist der universellere Ansatz. Eigentlich fehlt dem Ding in diesem Fall ein Rückgabewert für "nicht vergleichbar".

Am wichtigsten ist imho, das so etwas gut dokumentiert ist. Das scheint es nicht zu sein*

* OK, dass ist für viele Bibliotheken wohl ein Wunschtraum. Soll also kein Bashing werden