Custom Record Freigabe verkettete liste

[Sequitar]

Danke für deine Rückmeldung.
Anstatt des (noch) nicht verfügbaren destructors habe ich eine standard Procedure "free" eingeführt die das übernimmt.
Ich habe damit noch mal verschiedene tests durchgeführt:
-Erstellung und implizite conversion nach string - OK
-Vergleich rec1 vs rec2 -OK
-Vergleich a:=trec.create </=/> b:=trec.create - OK
-Länge, conversion nach byte / integer - OK
!:
-Vergleich: trec vs uint - n. OK, da hier für das uint eine conversion durchgeführt wird. Ich denke mal, ich müsste evtl die implizite conversion hier umkehren, um keine dangling variable zu haben?

Danke für den Tip mit der Tlist. ich war der Meinung, dass man da immer hin und her kopieren müsste, daher dachte ich mir die verkettete liste sei ggf. einfacher zu handeln (also einfügen,löschen etc durch einfaches umbiegen) und hätte weniger Overhead.

Zitat von Blup:

Zitat von Sequitar:

Wie kann ich den speicher denn hier wieder sauber freigeben?

Das funktioniert nicht, da es für Records leider keinen virtuellen Destructor gibt, den man überschreiben könnte.
Mit dem Pointer auf den nächsten Record weis der Delphi-Compiler nichts anzufangen.

Warum speicherst du deine Ziffern in einer verketten Liste von Records?
Ein einfacher String oder ein dynamisches Array können fast beliebige Anzahl von Ziffern in einem Record aufnehmen.

Verkettete Listen sind eher etwas für Lernübungen mit Pointern. Im Normalfall sind Array bzw. TList schneller und einfacher zu benutzen.

[himitsu]

Managed sind die neuen Records, wenn du die dazu machst und die 3 neuen Operatoren ordentlich benutzt.


was echtes/automatisches "managed" betrifft, welches es schon seit jahrzehnten gibt.
mit Strings gab es immer die wenigsten Probleme, aber darin Binärdaten zu verwalten ist nicht immer einfach.

Was ich aber seit Jahren gut nutzen könnte war ein F: TArray<record ... end>; mit der Länge 0 oder 1.
Das funktionierte sowohl im Windows, also auch genau gleich im NextGen (Android und bestimmt auch iOS)
Man muß nur wissen, das Arrays (außer bei den Strings) kein CopyOnWrite besitzen, wenn man auf Felder des Arrays schreibend zugreift.
Also wenn soeine Recordvariable kopiert wurde, dann wurden nur die Arrayzeiger kopiert und der ReferenzCounter erhöht, welches man aber beim Aufruf einer Recordmethode vor dem Zugriff prüfen kann, falls es nötig ist.
Jetzt, mit den neuen CustomManaged-Operatoren, kann man da nun geziehlt drauf reagieren, direkt beim Kopieren alles so behandeln, wie man es für nötig hält.


Ansonsten sind die neuen "Custom Managed Records" eine super Sache und erleichtern theoretisch die Speicherverwaltung enorm (so lange man nicht drauf angewiesen ist ältere Delphi-Versionen unterstüzen zu müssen, z.B. bei der Komponentenentwicklung)

Aber DU mußt eben mit den 3 neuen Funktionen (Initialize/Copy/Finalize) ordentlich arbeiten (viel üben) und dann haben die Records ein echt gutes Potential.



Ein Projekt mit einer mehrfach verketteten Liste hatte ich auch nun endlich mal wieder angefangen neu zu überarbeiten, aber ich kann mich seit Gestern nicht mehr mit meinem Computer daheim verbinden.
Hatte die letzten Jahre viel mit den oben genannten Krücken gearbeitet, aber die ersten Tests mit den neuen CustomManaged-Operatoren sahen eigentlich sehr gut aus.


jupp, virtueller Destructor ist nicht
und falls man es benötigt, muß man sich selber eine Referenzzählung bauen
oder eben nochmals ein Interface im Record verpacken, falls mehrere Variablen auf den gleichen Inhalt zeigen können.

also wenn man intern mit "ungemanagten" Pointern arbeitet, dann muß man schon sehr aufpassen und viel beachten.
(wie gesagt, meine Hilfe/Krücke war bisher TArray<> mit Länge 1 und dessen Referenzzählung)