AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Referenz Verwaltung

Ein Thema von Jonas Shinaniganz · begonnen am 21. Jun 2012 · letzter Beitrag vom 22. Jun 2012
Antwort Antwort
Seite 2 von 2     12
Namenloser

Registriert seit: 7. Jun 2006
Ort: Karlsruhe
3.724 Beiträge
 
FreePascal / Lazarus
 
#11

AW: Referenz Verwaltung

  Alt 22. Jun 2012, 00:28
@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.
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#12

AW: Referenz Verwaltung

  Alt 22. Jun 2012, 01:47
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.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benutzerbild von BUG
BUG

Registriert seit: 4. Dez 2003
Ort: Cottbus
2.094 Beiträge
 
#13

AW: Referenz Verwaltung

  Alt 22. Jun 2012, 02:22
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.

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
Intellekt ist das Verstehen von Wissen. Verstehen ist der wahre Pfad zu Einsicht. Einsicht ist der Schlüssel zu allem.

Geändert von BUG (22. Jun 2012 um 02:24 Uhr)
  Mit Zitat antworten Zitat
Namenloser

Registriert seit: 7. Jun 2006
Ort: Karlsruhe
3.724 Beiträge
 
FreePascal / Lazarus
 
#14

AW: Referenz Verwaltung

  Alt 22. Jun 2012, 02:39
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.

Geändert von Namenloser (22. Jun 2012 um 02:42 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Jonas Shinaniganz
Jonas Shinaniganz

Registriert seit: 30. Aug 2011
249 Beiträge
 
Delphi XE5 Ultimate
 
#15

AW: Referenz Verwaltung

  Alt 22. Jun 2012, 09:18
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!
Die Leiter der Entwicklungsabteilung dreht total am Mausrad!
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#16

AW: Referenz Verwaltung

  Alt 22. Jun 2012, 09:49
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.
  Mit Zitat antworten Zitat
Benutzerbild von Jonas Shinaniganz
Jonas Shinaniganz

Registriert seit: 30. Aug 2011
249 Beiträge
 
Delphi XE5 Ultimate
 
#17

AW: Referenz Verwaltung

  Alt 22. Jun 2012, 11:22
... kann gelöscht werdem

Geändert von Jonas Shinaniganz (22. Jun 2012 um 11:31 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Jonas Shinaniganz
Jonas Shinaniganz

Registriert seit: 30. Aug 2011
249 Beiträge
 
Delphi XE5 Ultimate
 
#18

AW: Referenz Verwaltung

  Alt 22. Jun 2012, 15:51
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.
Die Leiter der Entwicklungsabteilung dreht total am Mausrad!
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 07:53 Uhr.
Powered by vBulletin® Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf