Referenz Verwaltung

[Namenloser]

@shmia: Nicht jede Anwendung ist eine Formularanwendung.

Ich stelle mir jetzt mal beispielhaft ein Spiel vor: Es geht um Raketen und Raketenabwehrsysteme, jede Rakete ist ein Objekt. Wenn ein Raketenabwehrsystem eine feindliche Rakete detektiert, schickt es eine Abwehrrakete los, die die Rakete verfolgt. Dazu wird der Abwehrrakete bei Erstellung eine Referenz auf die feindliche Rakete gegeben.

Die Abwehrrakete liest nun bei jedem Bewegungsschritt die Position der feindlichen Rakete aus und passt entsprechend ihre Flugrichtung an. Wenn die Abwehrrakete mit der feindichen Rakete kollidiert, explodieren beide und die Objekte werden freigegeben.

Soweit so gut – aber was, wenn es ein zweites Raketenabwehrsystem gibt, das ebenfalls eine Abwehrrakete auf das gleiche Ziel losgeschickt hat? Dann befindet sich die Rakete des 2. Abwehrsystems noch in der Luft, während die feindliche Rakete explodiert – und verfolgt forthin ein Objekt, das gar nich mehr existiert.

[Sir Rufo]

Zitat von NamenLozer:

Soweit so gut – aber was, wenn es ein zweites Raketenabwehrsystem gibt, das ebenfalls eine Abwehrrakete auf das gleiche Ziel losgeschickt hat? Dann befindet sich die Rakete des 2. Abwehrsystems noch in der Luft, während die feindliche Rakete explodiert – und verfolgt forthin ein Objekt, das gar nich mehr existiert.

Das ist dann falsch implementiert
Denn es ändert sich bei der "Zerstörung im Spiel" erst mal nur der Zustand in "zerstört". Deshalb muss aber das Objekt selber nicht gleich zerstört werden.

Hier würde sich auch die Verwendung von Interfaces anbieten.

[BUG]

Zitat von Sir Rufo:

Hier würde sich auch die Verwendung von Interfaces anbieten.

Ich glaube, es ging eher darum, klar zu machen, dass eine hierarchische Organisation von Objekte, wie sie shmia fordert, nicht immer sinnvoll/möglich ist.

Zitat von shmia:

Wenn man sich die Lebenszeit eines Objekts als Rechteck vorstellt, dann besteht die Kunst darin, die Rechtecke so ineinander zu schachteln, dass sich die Grenzen nicht überschneiden.

Um mir die Lebenszeit eines Objekts als Rechteck und nicht auf einem Zeitstrahl vorzustellen, fehlt mir allerdings die Phantasie

[Namenloser]

Zitat von Sir Rufo:

Zitat von NamenLozer:

Soweit so gut – aber was, wenn es ein zweites Raketenabwehrsystem gibt, das ebenfalls eine Abwehrrakete auf das gleiche Ziel losgeschickt hat? Dann befindet sich die Rakete des 2. Abwehrsystems noch in der Luft, während die feindliche Rakete explodiert – und verfolgt forthin ein Objekt, das gar nich mehr existiert.

Das ist dann falsch implementiert
Denn es ändert sich bei der "Zerstörung im Spiel" erst mal nur der Zustand in "zerstört". Deshalb muss aber das Objekt selber nicht gleich zerstört werden.

Ja, in der Regel implementiert man das in der Praxis auch so. Aber das Problem bleibt letztlich trotzdem, denn irgendwann muss man das Objekt endgültig entfernen, wenn man kein Memory Leak haben will. Das Beispiel sollte aber sowieso nur zur Veranschaulichung dienen.

Man kann immer alles auch anders lösen, keine Frage – aber man kann auch auf Klassen als Sprachkonstrukt verzichten und stattdessen wieder mit Records und Funktionen programmieren. Klassen erleichtern aber die Arbeit; Smart-Pointers ebenso.

[Jonas Shinaniganz]

Okay nachdem Ich alles sorgfältig gelesen habe entscheide Ich mich definitiv für "Smart Pointer".

Pros:
- Ich werde keine Referenzen mehr haben die auf freien Speicher zeigen und kann vor Zugriffen auf NIL prüfen
- Meine Objekte sind sehr "verworren " und die Lebenszeit ist schwer abzuschätzen, Smartpointer bieten sich an
- Designfehler wurden in der Vergangenheit gemacht und es ist nicht möglich diese jetzt anzugehen

Cons:
- Das erkaufe Ich mir durch ermöglichen/fördern von schlechtem Design
- Die Implementation ist scheinbar halbherzig weil es kein vollständiger Garbagecollector ist
- Beim mischen von Interfaces und Objecten muss man vorsichtig sein

Das Ich Globale Variablen vermeiden soll und werde habe Ich schon vor längerer Zeit für mich entschieden.

Also insgesammt kann ein Smartpointer scheinbar nicht schaden, er HINDERT einen ja nicht an gutem Design und löst mein Problem.
Deswegen entscheide Ich mich für Smartpointer und lese jetzt eure Verweise um eine möglichst schnittige Implementierung hinzubekommen,

beste Grüße!

[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.