Eine ganz dumme Frage:

Angenommen man hat eine Collection (List, Dictionary, …) von Records, z.B. TMyRecord . Wenn man bei diesen Collections keinen IEqualityComparer<TMyRecord> angibt dann wird ein Default-Comparer genommen der stumpf die Bytes im Speicher vergleicht.

Bei Records mit Padding kann so eine Gleichheitsprüfung natürlich funktionieren, muss aber nicht. Das Problem: Hier wird im Code gerne vergessen bei solchen Collections auch den Comparer anzugeben. Unit-Tests decken das meist auch nicht auf da hier Records frisch angelegt werden, die Padding-Bytes alle Null sind und alles klappt.

In den Unit-Tests kann man natürlich explizit hingehen, die Padding-Bytes manuell mit Mustern beschreiben und schauen ob dann noch alles klappt - Aber da muss man auch erst einmal dran denken!


Gibt es einen Trick? Oder hilft hier nur Haue?

Gewalt ist immer eine Lösung!

Ich habe schlechte Erfahrung mit Records in Collections gemacht. Dadurch das beim Zugriff nicht das eigentliche Record angefasst wird, sondern man eine Kopie bekommt, ist halt irgendwie oll.
Am Ende nehme ich immer Klassen als stumpfe DTOs. Nur öffentliche Felder, ohne Properties. Die kommen dann ggf. sogar einfach in TObjectList/Dict/Whatever und mit Verwaltung und gut.

Nachtrag: Wenn man nicht will, das die Container-Klasse die Speicherverwaltung übernimmt, bekommt das DTO ein niedliches Interface dran und alles weiter läuft dann nur darüber.

Werttypen sind mir oft eigentlich ganz sympathisch da ich mir keine Sorgen machen muss dass jemand die Dinger verändert da jeder nur eine Kopie bekommt. Das jetzt auf Referenztypen (TObject/IInterface) umzubauen graut es mir etwas vor...

Vielleicht kommen in Delphi ja tatsächlich irgendwann die impliziten Record-Konstrukturen, hier könnte man dann in jedem DTO seinen Speicher erstmal mit einem gepflegten self := Default(TMyRecord) initialisieren und wäre all diese Sorgen los...

Ich habe mir einen Generator für solche Klassen gemacht. Erstmal ein interface mit properties was man haben will (ohne Getter). Dann gibts dazu Klassen, mit readonly properties, Daten kommen beim Konstruktor rein. (Dazu kommen 1:1 Records mit Methoden um von und in eine solche Klasse zu wandeln. Die Records sind aber nur für temporäre Zwecke gedacht.)

Eigene Ableitungen und im falle von tkRecord einen etwas schlaueren comparer bauen, der Feld für Feld vergleicht oder auf einen vorhandenen equals operator zurückgreift.

P.S. Hab ich auf meiner Liste für Spring4D

Unterklassen von Collections zu bilden bin ich normalerweise kein Freund von, aber hier klingt das schon sinnig. Ich tüftel da mal etwas herum... 🤔

Kannst du bei Gelegenheit ausführen was du vorhast?

Ich versuche bei Spring4D in den nächsten Tagen auch mal eine ganz konkrete Problembeschreibung mit PR was ich an den Dictionaries ändern würde einzureichen. Die TValueCollection eines TDictionary<X,Y> schert sich z.B. überhaupt nicht um den übergebenen Comparer wenn man mit Contains(..) schaut ob sie etwas enthält...

Zitat von Der schöne Günther:

Kannst du bei Gelegenheit ausführen was du vorhast?

Für comparer dasselbe machen, wie in Spring.EqualsRec2Rec: zuerst nach equals operator schauen, ansonsten Feldvergleich (bisschen anders als dort, fällt mir grad auf, damit evtl Feld paddings berücksichtigt werden).

Zitat von Der schöne Günther:

Die TValueCollection eines TDictionary<X,Y> schert sich z.B. überhaupt nicht um den übergebenen Comparer wenn man mit Contains(..) schaut ob sie etwas enthält...

Das ist in 1.3 (develop) schon gefixt.

Und ich dachte ich kann endlich auch mal etwas beitragen, und wenn es nur zwei Zeilen sind 😪

Das nächste mal schaue ich direkt in den aktuellen Zweig...