Referenz Verwaltung

[Furtbichler]

Wenn ich mein Programmdesign so aufbaue, das es für alle Instanzen jeweils eine Entität gibt, die dafür zuständig ist (ein anderes Objekt oder eine Klasse bzw. die Unit für unsere globalen Freunde), dann stellt sich das Problem nicht, das ich auf Instanzen zugreife, die nicht mehr existieren. Eine Ausnahme stellen zirkuläre Bezüge dar, die dann aber aufgelöst werden können, sodaß die Grundregel (Zuständigkeiten!) wieder greift.

Ich möchte die Kontrolle haben, wann genau ein Objekt freigegeben wird.

Es kann sein, das ich dann im Design etwas statischer agieren muss, und nicht mehr so elegant arbeiten kann. Aber sicherer bin ich damit in jedem Fall. Wenn man das stringent durchzieht, hat so ein Design auch eine gewisse Ordnung bzw. Eleganz. Ja gut, altbacken. Aber solide. Die Abhängigkeiten sind nur in einer Richtung.

Bei Interfaces habe ich diese natürlich Probleme nicht. Sie sind ein mächtiges Werkzeug, aber ich muss damit umgehen können.

Arbeite ich mit Interfaces dann weiss ich nicht, wann die Objekte freigegeben werden, was ganz praktisch ist. Aber beim Design muss ich aufpassen, das ich nicht Objekte wie Kraut und Rüben (Zirkuläre Bezüge) instantiiere und Abhängigkeiten erzeuge, die ich nicht mehr verstehe.

[Jonas Shinaniganz]

... kann gelöscht werdem

[Jonas Shinaniganz]

Ich bin auch noch über ein altes Thema gestolpert:

http://www.delphipraxis.net/100110-v...ls-zeiger.html

Der arme neomic hat sich zum Schluss eine Steuerung gebastelt die Ich in einem Projekt ab 3 Units nicht mehr verwenden möchte
Da konnte ich mich doch glatt selbst wiedererkennen!

Aber ein Sehr wertvoller Beitrag von Dezipaitor. (Für mich "Sehr wertvoll")

Zitat:

Also der Zeiger an sich ist einfach eine Zahl. Die Zahl gibt ja an, wo im Speicher sich die Information zum Auto befindet. Wenn du nun diesen Zeiger kopierst, dann wird nur der Wert kopiert und du hast zwei gleiche Werte,die auf denselben Speicher zeigen. Wenn du nun einen Wert auf 0 (also nil) setzt, dann bleibt der andere Zeiger unbeheligt davon.
Wenn du nun mehrere Zeiger auf das Auto hast und du verwendest einen Zeiger, um den Speicher des Autos zu löschen, dann hast du plötzlich mehrere Zeiger, die an die alte Stelle der Autoinformation zeigen. Jetzt ist der Speicher jedoch ungültig. Das führt zu Problemen (Merkwürdiges, AV).
Es gibt eine Technik mit dem Namen Referenzzählung (Reference counting), die macht folgendes, um das Problem zu verhindern:
Das Objekt (Auto) bekommt eine Integer Variable, die angibt, wieviele Zeiger auf das Objekt zeigen. Wenn diese Variable 0 ist, dann kann das Objekt gefahrlos gelöscht werden. Wenn es größer als 0 ist, dann darf es nicht gelöscht werden.
Bei jedem Erzeugen eines Zeigers auf das Objekt, wird diese Variable um eines erhöht. Bei jedem Löschen (nil-setzen!!) eines Zeigers auf das Objekt, wird diese Variable um eins erniedrigt. Für Singlethread Programme wars das auch schon.

Eine zweite Technik (deren Namen ich vergessen habe), funktioniert so:
Es gibt nur eine Zeigervariable (Hauptzeiger), die direkt auf das Objekt zeigt. Alle neuen Zeiger zeigen auf diese Zeigervariable. Folgedessen muss diese Zeigervariable im Heap existieren (erzeugt durch GetMem oder New). Wenn man auf das Objekt zugreifen will,
dass muss man zweimal referenzieren. Zuerst den Zeiger auf den Hauptzeiger und dann darüber auf das Objekt. Alle Zeiger zeigen eben zuerst auf den Hauptzeiger. Wenn man nun das Objekt löscht, dann setzt man den Hauptzeiger auf nil (nicht FreeMem der Dispose machen!) und alle andere Zeiger zeigen dann auf nil.
Natürlich muss man diese Hauptzeiger auch irgendwann mal löschen. Mann kann sie mit der Referenzählung verwalten oder in einer List verwalten, die dann ganz zum Schluss gelöscht wird.