Referenzen auf ungültige Objekte

[stahli]

(Ich habe es schon mal angesprochen, will es aber nochmal strukturierter angehen.)

Das Problem:
- Objekt O ist instantiiert.
- Eigenschaft X.MyO zeigt auf O.
- Variable MyO zeigt ebenfalls auf O.

Wird Objekt O freigegeben (vielleicht sogar mit FreeAndNil(O)) zeigen X.MyO und MyO auf einen "ungültigen" Speicherbereich.

Eine Lösung sollen Interfaces bzw. Referenzzähler bieten. Durch diese wird O tatsächlich erst freigegeben, wenn die Referenzen von X.MyO und MyO quasi abgemeldet werden.
Wie ich das verstanden habe, funktioniert dies so mit Interfaces im Delphi sowie auch mit der GarbageCollection im .NET.
Das läuft auch unter dem Begriff "SmartPointer".

Soweit richtig?

Das ist aber noch nicht der Ansatz, den ich mir wünschen würde.
Ich hätte gern, dass X.MyO und MyO bei O.Free automatisch auf nil gesetzt werden.

Derzeit löse ich das in meinem Projekt händisch (durch die Verwaltung von eigenen Listen), da kann es jedoch passieren, dass ich einige Objekte vergesse und später nachtragen muss.

Daher zwei Fragen:

1) Könnte/Sollte Delphi (optional) nicht eine Funktion bieten, die eine solche Verwaltung übernimmt?
Man könnte Objekte regestrieren, die "überwacht" werden sollen:

Delphi-Quellcode:

RegisterValidObject(O)

Das Objekt O wird in eine Liste aufgenommen. Wird das Objekt freigegeben, wird es aus der Liste entfernt.
Dann könnte man mit

Delphi-Quellcode:

IsValidObject(X.MyO)

bzw.

Delphi-Quellcode:

IsValidObject(MyO)

prüfen, ob das Objekt noch gültig (noch in der Kontroll-Liste enthalten) ist.
Das wäre so ähnlich zu sehen, wie

Delphi-Quellcode:

Assigned(X.MyO)

, wobei nicht nur auf nil geprüft wird, sondern auf die Existenz des referenzierten Objektes.

2) Weiterhin wäre es wünschenswert, wenn die Referenzen automatisch "genilt" würden.
Dazu müsste wohl zusätzlich verwaltet werden, ob eine Variable, ein Objektfeld oder eine Objekteigenschaft das zu überwachende Objekt referenziert.
Bei der Freigabe von O müssten alle diese registrierenten Referenzen automatisch auf nil gesetzt werden.


Im Moment realisiere ich den zweiten Weg selbst durch Nutzung der neuen RTTI-Möglichkeiten.
Ich durchsuche meine Objekte nach überschreibbaren Eigenschaften, die auf Objekte zeigen, prüfe, ob das betreffende Objekt noich existiert und setze andernfalls diese Eigenschaft auf nil.
Das funktioniert, ist aber auf meine eigenen Objekte beschränkt und berücksichtigt keine Variablenreferenzen.

Eine Delphi-native Lösung hielte ich für nützlich und grundsätzlich wohl auch für realisierbar.
Wie seht Ihr das?

[WM_CLOSE]

Man könnte ein TSmartObject einführen, aber dann müssten zwangsweise alle Klassen, die den SmartPointer unterstützen von ebendieser Klasse abstammen.
Ich weiß nicht, ob man mit der RTTI so weit kommt.

[r2c2]

Zitat:

Zitat von stahli (Beitrag 1088351)

Wird Objekt O freigegeben (vielleicht sogar mit FreeAndNil(O)) zeigen X.MyO und MyO auf einen "ungültigen" Speicherbereich.

richtig.

Zitat:

Eine Lösung sollen Interfaces bzw. Referenzzähler bieten.

Ja, kann man dafür nehmen.

Zitat:

Durch diese wird O tatsächlich erst freigegeben, wenn die Referenzen von X.MyO und MyO quasi abgemeldet werden.

So in etwa. Ja.

Zitat:

Wie ich das verstanden habe, funktioniert dies so mit Interfaces im Delphi sowie auch mit der GarbageCollection im .NET.

Is AFAIK anders realisiert, aber so kannst du dirs vorstellen.

Zitat:

Das läuft auch unter dem Begriff "SmartPointer".

Den Begriff "smart pointer" kenn ich eher aus C++. Da beschreibt er ein Konzept mit ähnlichem Zweck. Interfaces würde ich aber erstmal nicht als smart pointer bezeichnen, auch wenn der Effekt ähnlich ist.

Zitat:

1) Könnte/Sollte Delphi (optional) nicht eine Funktion bieten, die eine solche Verwaltung übernimmt?
Man könnte Objekte regestrieren, die "überwacht" werden sollen:

Delphi-Quellcode:

RegisterValidObject(O)

Das Objekt O wird in eine Liste aufgenommen. Wird das Objekt freigegeben, wird es aus der Liste entfernt.
Dann könnte man mit

Delphi-Quellcode:

IsValidObject(X.MyO)

bzw.

Delphi-Quellcode:

IsValidObject(MyO)

prüfen, ob das Objekt noch gültig (noch in der Kontroll-Liste enthalten) ist.
Das wäre so ähnlich zu sehen, wie

Delphi-Quellcode:

Assigned(X.MyO)

, wobei nicht nur auf nil geprüft wird, sondern auf die Existenz des referenzierten Objektes.

Prinzipiell möglich. Das ist aber doch genau das, was du momentan tust. Oder hab ich dich da falsch verstanden?

Zitat:

2) Weiterhin wäre es wünschenswert, wenn die Referenzen automatisch "genilt" würden.
Dazu müsste wohl zusätzlich verwaltet werden, ob eine Variable, ein Objektfeld oder eine Objekteigenschaft das zu überwachende Objekt referenziert.
Bei der Freigabe von O müssten alle diese registrierenten Referenzen automatisch auf nil gesetzt werden.

Und das ist ohne erheblichen Aufwand eben nicht möglich. Können die neuen records eigentlich auch Destruktoren haben? Wenn ja, könnte man sich damit mehr oder weniger die oben erwähnten Smart Pointer nachbauen. Das wäre dann zumindest sowas Ähnliches.

Zitat:

Eine Delphi-native Lösung hielte ich für nützlich und grundsätzlich wohl auch für realisierbar.
Wie seht Ihr das?

Jetzt kommt meine eigentlich Antwort auf deine Frage: Ich halte das für in den meisten Fällen unnötig. Wenn du einen sauberen Ansatz hast, brauchst du das alles nicht. Insbesondere halte ich deine Workarounds für Frickellösungen, die mehr Probleme schaffen als lösen. Ich will dein Vorhaben damit nicht generell verteufeln. Manchmal braucht man eben - leider - Frickllösungen. Ich denke aber, du solltest dir nochmal genau überlegen, ob du nicht ein konzeptionelles Problem hast. Sag mal was zu deinen Objekten. Welche sind es, warum brauchst du die und warum kommt es zu diesen Problemen mit dem Freigeben (also nicht technisch, sondern inhaltlich gesehen)? Vielleicht gibts ja eignen besseren Weg...

mfg

Christian

[Bernhard Geyer]

Mach es doch wie auch tausendfach in der VCL gemacht wird. Wenn du eine Zeiger auf ein objekt hast trägst du dich in die Notify-Liste für die Freigabe ein. Diese wird vor der Freigabe des Objekts durchlaufen und das andere Objekt kann seinen Member nillen.

[WM_CLOSE]

man sollte auch nicht vergessen, dass die "Pointer" in -NET keine klassischen Cardinal sind, sondern Klassen, so wie fast alles in .NET.
Da lassen sich Zeiger wunderbar um einen Notifier erweitern, dass allen anderen Zeigern sagt, dass sie jetzt ungültig sind.
Aber in Delphi sind die Zeiger ja Passiv.
Man könnte über Records diese .NET-Zeiger nachbauen, aber mit der IDE kann man dann vermutlich nicht mehr rechnen:
d.h. Kein InteliSense usw. Das Prob hatten wir scon mit den neuen Generics - andauernd fehler, die gar keine waren...
Und die Destruktoren für Records muss man dem Compiler auch erst mal einhämmern.(Aber gehen tut es)

[stahli]

@r2c2:
Mein Projekt arbeitet komplett mit Objekten. Diese beinhalten die Daten und die Geschäftslogik.
Obendrauf gibt es eine GUI-Ebenene zur Darstellung und Bearbeitung der Daten.

Die Objekte halten Referenzen aufeinander (ein Verein verwaltet eine Liste von Mitgliedern, jedes Mitglied enthält eine Instanz einer Person. Jedes Spiel hat zwei Spielparteien. Jede Spielpartei hat ein oder zwei Spieler. Jeder Spieler hat eine Referenz (keine Instanz) auf eine Person. Eine Funktion ermittelt übergeordnete Komponenten - Z.B. ein Turnier, in dem ein bestimmtes Spiel enthalten ist).

Wird z.B. ein Personenobjekt gelöscht, müssen die anderen Komponenten, die eine Referenz darauf enthalten, diesen ungültigen Zeiger nilen.

Ich habe eine Lösung aus den beiden o.g. Punkten 1 + 2 realisiert. Dies funktioniert für meine Objekte schon sehr gut.

ABER ich halte z.B. auch in einem dynamischen Formular in einer Eigenschaft eine Referenz z.B. auf ein Turnierobjekt.

Wird dieses Turnierobjekt freigegeben, muss ich diese Formulareigenschaft explizit nilen - sonst geht das ggf. schief.

Wenn es dafür eine allgemeine Lösung gäbe, fände ich das hilfreich.


@Bernhard:
Das gibt es aber doch nur in Listen, meine ich!?
Oder kannst Du eine Lösung für mein o.g. Beispiel zeigen?


@WM_CLOSE:
Der Umweg über Records hört sich kompliziert an.
Ich hatte die Hoffnung, dass der Compiler (optional) einfach eine Liste der Referenzen anlegt und bei späteren Zugriffen "korrigiert".
Im Grunde mache ich das ja schon für meine Objekte, das ist aber noch nicht allgemein genug einsetzbar.

[alzaimar]

Ich kenne dein Konzept nicht, halte aber Referenzen, die -wupps- plötzlich invalid werden können, für kein gutes Design, auch wenn ich die Referenzen per Notify auf Nil setzen kann.

Deine Programmlogik kann dann an beliebigen Stellen gegen die Wand fahren. Du weisst nie, wann das der Fall sein wird, vielleicht sogar während einer elementaren Operation...

Wenn Du dir sicher bist, das dieser verteilte Zugriff
Du könntest diese Objekte auch über das Handle-Konzept realisieren:
Du instantiierst ein Objekt und bekommst von einer zentralen Vewaltung ein Handle zurück.

Du verwendest das dahinterliegende Objekt, indem Du es per Handle anforderst und automatisch gegen instantane Freigabe sperrst. Zum Ende der Verwendung gibst Du die Anforderung wieder frei.

Die Freigabe ist dann ein "gib es dann frei, wenn alle Anforderungen zurückgegeben wurden".

Du müsstest im Code nur dafür sorgen, das die Rückgabe so schnell wie möglich geschieht.

Delphi-Quellcode:

MyObject := ObjectManager.AcquireObjectByHandle(MyHandle);
If MyObjecty<>Nil Then 
  Try
    DoSomethingWith(MyObject);
    DoSomethingElseWith(MyObject);
  Finally
    ObjectManager.ReleaseObjectByHandle(MyHandle);
    // MyObject ist nun nicht mehr gültig
  End
Else
  Raise EHonestlyIDontKnowHowToHandleThis.Create;

[Lemmy]

Guten Morgen,

was spräche denn dagegen hier das Observer-Pattern einzusetzen? Der Observer wird vom Subject informiert wenn dieses freigegeben wird. Damit kann der Observer entsprechend reagieren und die Referenz entfernen...

Grüße

[Blup]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1088471)

Mach es doch wie auch tausendfach in der VCL gemacht wird. Wenn du eine Zeiger auf ein objekt hast trägst du dich in die Notify-Liste für die Freigabe ein. Diese wird vor der Freigabe des Objekts durchlaufen und das andere Objekt kann seinen Member nillen.

Zitat:

Zitat von Lemmy (Beitrag 1088527)

Guten Morgen,

was spräche denn dagegen hier das Observer-Pattern einzusetzen? Der Observer wird vom Subject informiert wenn dieses freigegeben wird. Damit kann der Observer entsprechend reagieren und die Referenz entfernen...

Grüße

Das ist ein klassischer Fall für das Observer-Pattern und in der VCL auch so realisiert.
In allen existierenden Objekten nach einer Referenz zu suchen, halte ich für einen Designfehler.

[r2c2]

Zitat:

Zitat von stahli (Beitrag 1088486)

Mein Projekt arbeitet komplett mit Objekten. Diese beinhalten die Daten und die Geschäftslogik.
Obendrauf gibt es eine GUI-Ebenene zur Darstellung und Bearbeitung der Daten.

Das ist soweit vollkommen normal.

Zitat:

ein Verein verwaltet eine Liste von Mitgliedern,

OK.

Zitat:

jedes Mitglied enthält eine Instanz einer Person.

Huch. Wieso das? Ich denke doch eher ein Mitglied *ist* eine Person.

Zitat:

Jedes Spiel hat zwei Spielparteien. Jede Spielpartei hat ein oder zwei Spieler.

OK.

Zitat:

Jeder Spieler hat eine Referenz (keine Instanz) auf eine Person.

Und wieder: Ich denke eher ein Spieler *ist* eine Person.

Zitat:

Eine Funktion ermittelt übergeordnete Komponenten - Z.B. ein Turnier, in dem ein bestimmtes Spiel enthalten ist).

Versteh ich nicht.

Zitat:

Wird z.B. ein Personenobjekt gelöscht, müssen die anderen Komponenten, die eine Referenz darauf enthalten, diesen ungültigen Zeiger nilen.

Hier solltest du dir genau überlegen, was die Semantik des Löschens ist. Warum wird eine Person überhaupt gelöscht? Und wer tut das? Und was genau soll da passieren? Solche Probleme lösen sich oft durch die Beantwortung der folgenden Fragen:
- Zu wem gehört das Objekt?
- Wer ist dafür zuständig es frei zu geben?
- Wann und warum wird das Objekt freigegeben?

Im Idealfall hat man die folgenden beiden Fälle:
- Ein Objekt wird nur innerhalb einer Methode benutzt ==> Dann Create und Free mit try..finally in der Methode
- Ein Objekt gehört zu einem anderen Objekt (Komposition) ==> Dann create im Konstruktor und Free im Destruktur.

Dadurch ergeben sich Baumstrukturen von "gehört-zu-Beziehungen" und man hat i.d.R. keine Probleme mit der ganzen Freigeberei. Wenn man jetzt doch mal "außer der Reihe" ein Objekt freigeben will, stellt sich wie immer die Frage wer dafür zuständig ist und ob der weiß, wo überall Referenzen rumfliegen. Wenn du n Klassendiagramm postest, könnt ich mal drübergucken. Ich vermute, dass da was mit den Zuständigkeiten nicht passt. Observerpattern udn Events wurden bereits genannt. Das sind Möglichkeiten die Kopplung zu reduzieren und so das Problem gar nicht erst entstehen zu lassen.

//Nachtrag:
@WM_CLOSE: Seit wann sind Pointer in .NET Klassen? Ich hab zwar schon lang kein .NET mehr gemacht, aber das wär mir neu.

mfg

Christian

[WM_CLOSE]

@Christian: es gibt theoretisch keine Pointer in .Net. Es gibt nur Referenzen. Auf diese Referenzen kann normalerweise nur das Framework bzw System.Object zugreifen. Wie gesagt: Man könnte eine Klasse x und einen Record y herstellen. Record y wird sich, wenn ihm ein Wert zugewiesen wird bei der entsprechenden Instanz von x melden. Wird nun der Destruktor der Instanz aufgerufen, nilt er allen ys. eigentlich relativ einfach.

[stahli]

Ich versuche mal, auif die genannten Punkte einzugehen:

Grundsätzlich will ich voranstellen, dass ich die Objekte auf Dauer komplett im Speicher halte. Ich erzeuge diese also nicht vorübergehend, um eine Methode auszuführen.
Die Objekte bilden die gesamte Turnierstruktur ab und beinhalten die Daten.
(Alternativ will ich die Daten (Felder) in eine Datenbank auslagern, aber die Struktur und die Geschäftslogik soll in den Objekten abgebildet werden.)

Zitat:

Zitat von alzaimar (Beitrag 1088526)

Die Freigabe ist dann ein "gib es dann frei, wenn alle Anforderungen zurückgegeben wurden".
Du müsstest im Code nur dafür sorgen, das die Rückgabe so schnell wie möglich geschieht.

Delphi-Quellcode:

MyObject := ObjectManager.AcquireObjectByHandle(MyHandle);

Dies entspricht ja m.E. in etwa meiner angedeuteten Funktion IsValidObject, es erfolgt eine Prüfung, ob das Objekt noch existiert. Also dafür habe ich schon eine Lösung.

Zitat:

Zitat von Lemmy (Beitrag 1088527)

Guten Morgen,

was spräche denn dagegen hier das Observer-Pattern einzusetzen? Der Observer wird vom Subject informiert wenn dieses freigegeben wird. Damit kann der Observer entsprechend reagieren und die Referenz entfernen...

Grüße

Da habe ich ja eigentlich nichts dagegen, nur wollte ich gern eine weniger aufwendige Lösung.
Bernhard bezog sich ja (wie ich jetzt denke) auch auf BEISPIELE in der VCL.
Klar kann man das regeln. Aber man muss den betreffenden Objekten Listen hinzufügen, ggf. Schnittstellen definieren und gegenseitig aufzurufende Methoden implementieren.

Ich hätte eben gern eine mehr oder weniger automatisierte Lösung. Wenn ICH das für meine Objekte kann (es funktioniert ja grundsätzlich sehr gut), kann ich mir vorstellen, dass die Emba-Profis das auch allgemein regeln könnten. Die Programmierer müssten dann eben weniger auf Observer-Pattern setzen und könnten sich eine Menge Arbeit sparen.

Variablen (Pointer) können auf dem Weg ja auch nicht abgesichert werden.

Ein wenig könnte das wie FastMM laufen, das überwacht ja auch Zugriffe auf freigegebene Objekte. Vielleicht ließe sich darauf aufbauend ja eine Lösung finden, dass Referenzen auf solche Objekte genilt werden. So etwa waren meine Überlegungen dazu.

Zitat:

Zitat von Blup (Beitrag 1088591)

Das ist ein klassischer Fall für das Observer-Pattern und in der VCL auch so realisiert.
In allen existierenden Objekten nach einer Referenz zu suchen, halte ich für einen Designfehler.

Meine Lösung funktioniert halt diskret und ohne großen Aufwand im Hintergrund.
Eine Observer-Lösung für alle betreffenden Objekte wäre halt sehr viel aufwendiger.
Für alle "echten Datenobjekte" funktioniert meine Lösung ohne Probleme.
Nur wenn ich mal zusätzliche Variablen oder Eigenschaften nutze, unterliegen diese nicht einer "Bereinigung".

Zitat:

Zitat von r2c2 (Beitrag 1088706)

Zitat:

ein Verein verwaltet eine Liste von Mitgliedern,

Huch. Wieso das? Ich denke doch eher ein Mitglied *ist* eine Person.

Eine Person gibt es nur einmal (mit Namen, Status etc). Diese Person kann Mitglied in einem Verein sein, Spieler in einer Mannschaft, Gastspieler in einer anderen Mannschaft oder sogar Schiedsrichter usw.
Deshalb wird dort die Referenz auf eine Person genutzt.

Zitat:

Zitat:

Eine Funktion ermittelt übergeordnete Komponenten - Z.B. ein Turnier, in dem ein bestimmtes Spiel enthalten ist).

Versteh ich nicht.

Ist ein Spiel beendet, wird das übergeordnete Turnier veranlasst, die Platzierungen neu zu berechnen. Das Spiel kennt sein übergeordnetes Turnier aber nicht direkt. Das wird über eine Funktion ermittelt.

Zitat:

Zitat:

Wird z.B. ein Personenobjekt gelöscht, müssen die anderen Komponenten, die eine Referenz darauf enthalten, diesen ungültigen Zeiger nilen.

Hier solltest du dir genau überlegen, was die Semantik des Löschens ist. Warum wird eine Person überhaupt gelöscht? Und wer tut das? Und was genau soll da passieren? Solche Probleme lösen sich oft durch die Beantwortung der folgenden Fragen:
- Zu wem gehört das Objekt?
- Wer ist dafür zuständig es frei zu geben?
- Wann und warum wird das Objekt freigegeben?

Das Personenobjekt wird gelöscht, wenn z.B. die Turnierveranstaltung gelöscht wird, da das Personenobjekt ein SubMember der Turnierveranstaltung ist.
Das Löschen wird durch den User veranlasst.
(Wann die Person nicht gelöscht werden darf (z.B. wenn sie schon gespielt hat) muss ich noch regeln - das wäre ja aber auch bei anderen Konzepten (SQL-DB) so).)

Zitat:

Im Idealfall hat man die folgenden beiden Fälle:
- Ein Objekt wird nur innerhalb einer Methode benutzt ==> Dann Create und Free mit try..finally in der Methode
- Ein Objekt gehört zu einem anderen Objekt (Komposition) ==> Dann create im Konstruktor und Free im Destruktur.

Das habe ich ja so realisiert. Es geht mir ja aber um die fremden Zugriffe z.B. auf ein Personenobjekt, die nicht dessen Owner sind.

[r2c2]

Zitat:

Zitat von WM_CLOSE

@Christian: es gibt theoretisch keine Pointer in .Net. Es gibt nur Referenzen.

Ja. Klar.

Zitat:

Auf diese Referenzen kann normalerweise nur das Framework bzw System.Object zugreifen.

Du meinst auf die Adresse, die hinter der Referenz steht. Ja.

Zitat:

Wie gesagt: Man könnte eine Klasse x und einen Record y herstellen. Record y wird sich, wenn ihm ein Wert zugewiesen wird bei der entsprechenden Instanz von x melden. Wird nun der Destruktor der Instanz aufgerufen, nilt er allen ys. eigentlich relativ einfach.

Das wären einfach die genannten Smart Pointer. Das heißt aber nicht, dass Referenzen selbst Objekte wären.

Zitat:

Zitat von stahli (Beitrag 1088793)

Zitat:

Zitat von r2c2 (Beitrag 1088706)

Zitat:

ein Verein verwaltet eine Liste von Mitgliedern,

Huch. Wieso das? Ich denke doch eher ein Mitglied *ist* eine Person.

Eine Person gibt es nur einmal (mit Namen, Status etc). Diese Person kann Mitglied in einem Verein sein, Spieler in einer Mannschaft, Gastspieler in einer anderen Mannschaft oder sogar Schiedsrichter usw.
Deshalb wird dort die Referenz auf eine Person genutzt.

Ja, das ist klar. Aber dann hast du keine zusätzlichen Mitglied-, Spieler- und Schiedsrichter-Klassen. Sondern der Verein hat einfach ne Liste von Personen als Mitglieder. Vielleicht ist das bei dir ja auch schon so und ich hab dich einfach falsch verstanden. Solltest du Rollen brauchen, die im Verhalten von dem normaler Personen abweisen, bietet sich das Decorator-Pattern an.

Zitat:

Ist ein Spiel beendet, wird das übergeordnete Turnier veranlasst, die Platzierungen neu zu berechnen. Das Spiel kennt sein übergeordnetes Turnier aber nicht direkt. Das wird über eine Funktion ermittelt.

Das wäre ein klarer Fall für Events. Für was ne Funktion, die erst suchen muss?

Zitat:

Das Personenobjekt wird gelöscht, wenn z.B. die Turnierveranstaltung gelöscht wird, da das Personenobjekt ein SubMember der Turnierveranstaltung ist.

Dann passiert das einfach im Destruktor.

Zitat:

Das Löschen wird durch den User veranlasst.

Und welches Objekt ist dafür zuständig? Darum geht es.

Zitat:

Das habe ich ja so realisiert. Es geht mir ja aber um die fremden Zugriffe z.B. auf ein Personenobjekt, die nicht dessen Owner sind.

Ja das ist klar. Aber hier stellt sich die Frage, was die fremden Objekte da zu suchen haben. "Don't talk to stragers".

- sind die "Fremden" weiter oben in der Hierarchie, können sie sicher sein, dass das Objekt noch exisiert. ggf. muss es über events benachrichtigt werden, aber oft ist noch nichtmal das erforderlich
- ist es niedriger in der Hierarchie, hat es das Objekt gar nicht zu kennen. Dann solltest du dein Konzept überarbeiten.
- ist es weder höher noch tiefer in der Hierarchie, sollte es entweder gar nix von dem Objekt wissen oder über Events benachrichtigt werden.

Das ist der normale Fall, so wie es alle Welt handhabt. Da etwas zu automatisieren, halte ich für gefährlich. Da werden Referenzen ungültig und ich krieg nix davon mit. Vor allem hat ein Objekt A nix an den Innereien von B zu schaffen. Das ist schon aus Prinzip eklig.

mfg

Christian

[stahli]

Zitat:

Zitat:

Zitat von stahli (Beitrag 1088793)

Eine Person gibt es nur einmal (mit Namen, Status etc). Diese Person kann Mitglied in einem Verein sein, Spieler in einer Mannschaft, Gastspieler in einer anderen Mannschaft oder sogar Schiedsrichter usw.
Deshalb wird dort die Referenz auf eine Person genutzt.

Ja, das ist klar. Aber dann hast du keine zusätzlichen Mitglied-, Spieler- und Schiedsrichter-Klassen. Sondern der Verein hat einfach ne Liste von Personen als Mitglieder. Vielleicht ist das bei dir ja auch schon so und ich hab dich einfach falsch verstanden. Solltest du Rollen brauchen, die im Verhalten von dem normaler Personen abweisen, bietet sich das Decorator-Pattern an.

Nein, ein Spieler und ein Schiedsrichter ist jeweils ein Objekt mit unterschiedlichen Eigenschaften und Methoden, dem jeweils eine Person "zugewiesen" wird (die Person ist dann wiederum eine Eigenschaft des Obektes - eigentlich ja nichts ungewöhnliches).
Die gleichen Zusammenhänge gibt es auch bei anderen Objekten. Egal warum nun ein Objekt freigegeben wird, sollen mögliche Referenzen darauf halt "angepasst" (genilt) werden.

Zitat:

Zitat:

Ist ein Spiel beendet, wird das übergeordnete Turnier veranlasst, die Platzierungen neu zu berechnen. Das Spiel kennt sein übergeordnetes Turnier aber nicht direkt. Das wird über eine Funktion ermittelt.

Das wäre ein klarer Fall für Events. Für was ne Funktion, die erst suchen muss?

Die Funktion durchläuft alle Owner ab dem Spiel und prüft, bis sie auf ein Turnierobjekt trifft.
Wenn ich ein Event verschicke, muss ich doch vorher auch den Adressaten ermitteln!?
Da erkenne ich keinen wirklichen Vorteil. Das ist auch eigentlich nicht mein Problem.

Zitat:

Zitat:

Das Personenobjekt wird gelöscht, wenn z.B. die Turnierveranstaltung gelöscht wird, da das Personenobjekt ein SubMember der Turnierveranstaltung ist.

Dann passiert das einfach im Destruktor.

Ja klar.

Zitat:

Zitat:

Das Löschen wird durch den User veranlasst.

Und welches Objekt ist dafür zuständig? Darum geht es.

Es ist doch rel. egal, wodurch ein Objekt gelöscht wird. WENN es gelöscht wird, will ich mögliche Referenzen darauf nilen.

Zitat:

Zitat:

Das habe ich ja so realisiert. Es geht mir ja aber um die fremden Zugriffe z.B. auf ein Personenobjekt, die nicht dessen Owner sind.

Ja das ist klar. Aber hier stellt sich die Frage, was die fremden Objekte da zu suchen haben. "Don't talk to stragers".

- sind die "Fremden" weiter oben in der Hierarchie, können sie sicher sein, dass das Objekt noch exisiert. ggf. muss es über events benachrichtigt werden, aber oft ist noch nichtmal das erforderlich
- ist es niedriger in der Hierarchie, hat es das Objekt gar nicht zu kennen. Dann solltest du dein Konzept überarbeiten.
- ist es weder höher noch tiefer in der Hierarchie, sollte es entweder gar nix von dem Objekt wissen oder über Events benachrichtigt werden.

Das ist der normale Fall, so wie es alle Welt handhabt. Da etwas zu automatisieren, halte ich für gefährlich. Da werden Referenzen ungültig und ich krieg nix davon mit. Vor allem hat ein Objekt A nix an den Innereien von B zu schaffen. Das ist schon aus Prinzip eklig.

Die Objektreferenzen sind ja nix ungewöhnliches. Macht ja schon DBGrid mit DataSource so. (Ich habe mir heute mal die Freigabeziehungen angesehen.)
Wenn die DataSource freigegeben wird, informiert diese halt (unter Zuhilfenahme komplexer Beziehungen, Listen und Methoden) das DBGrid, das dann seine Eigenschaft DataSource auf nil setzt.
Genau das passiert bei der Nutzung meiner Komponenten automatisch im Hintergrund, ohne dass sich der Programmierer darum kümmern muss.

Eine Lössung für meine Objekte habe ich damit, würde mir das aber auch als Grudsatzlösung wünschen.
Wenn Du das für gefährlich oder eklich hältst, dann muss ich das halt so hinnehmen.

Für lösbar halte ich das. Aber ok, ich gebe schon wieder Ruhe...


Dittsche hätte das aber sicher als Weltidee bezeichnet...

[Bummi]

Wenn Du eine eindeutige Referenz (1 Zeiger) hast kannst Du die Adresse im Konstruktor mit übergeben und im Destructor abräumen (auf nil setzen).
Allerdings kann es ja beliebig viele Kopien der Referenz geben (wie auch immer generiert/kopiert/zugewiesen) wer soll dann wissen was alles "genilt" werden soll.

[stahli]

Ich weiß das :wink:

So sehen zwei Objekte von mir aus.
Die zu nutzenden Eigenschaften sind mit einem Attribut gekennzeichnet:

Delphi-Quellcode:

  TodPlayer = class(TodOlympicCustom)
  private
    FPerson: TodPerson;
    function get_StateType: TStateType;
    procedure set_StateType(const Value: TStateType);
  protected
    function get_Person: TodPerson; virtual;
    procedure set_Person(const Value: TodPerson); virtual;  public
    constructor Create(AOwner: TComponent); override;
    destructor Destroy; override;
    function GetClubName: String;
    [AttrOd]
    property Person: TodPerson read get_Person write set_Person;  // EINE REFERENZ AUF EINE PERSON
    property StateType: TStateType read get_StateType write set_StateType;
  published
  end;

  TodMeleePlayer = class(TodPlayer)
  private
    FWin: Integer;
    FLose: Integer;
    FSetsP: Integer;
    FSetsC: Integer;
    FBallsP: Integer;
    FBallsC: Integer;
    FPlaced: Integer;  
    ...
  public
    IsFree: Boolean;
    Pos: Integer;
    constructor Create(AOwner: TComponent); override;
    destructor Destroy; override;
    ...
    [AttrOd]
    property Win: Integer read get_Win write set_Win;
    [AttrOd]
    property Lose: Integer read get_Lose write set_Lose;
    [AttrOd]
    property SetsP: Integer read get_SetsP write set_SetsP;
    [AttrOd]
    property SetsC: Integer read get_SetsC write set_SetsC;
    [AttrOd]
    property BallsP: Integer read get_BallsP write set_BallsP;
    [AttrOd]
    property BallsC: Integer read get_BallsC write set_BallsC;
    [AttrOd]
    property Placed: Integer read get_Placed write set_Placed;
    ...
  published
  end;

Und hier mal ein paar Auszüge, wie ich die Referenz-Nilung erledige.
Ich hoffe, dass das einigermaßen durchschaubar ist.
Der Schwachpunkt ist derzeit sicher der Timer, macht aber praktisch keine Probleme.
Optimieren lässt sich da sicher noch einiges. Aber der Ansatz erscheint mir angenehmer als komplexe Observer-Patterns.

Delphi-Quellcode:

  odList: TObjectList<Tod>;

constructor Tod.Create(AOwner: TComponent);
begin
  inherited;
  odList.Add(Self); // od-Objekt registrieren

  odClass := ClassName; // Klassendefinitionen für meine RTTI-Funktionen und Datenspeicherung
  if Self is Todl then
    odClass := Copy(odClass, 4 + 1, MaxInt)
  else
    odClass := Copy(odClass, 3 + 1, MaxInt);
  odName := odClass;

  odId := GetNewOdId; // eindeutige ObjektID zuweisen
end;

destructor Tod.Destroy;
begin
  odList.Extract(Self);  // Liste meiner od-Objekte
  odDestroy(Self);
  inherited;
end;

procedure odDestroy(od: Tod);
var
  I: Integer;
begin
  I := 0;
  while I <= odDataSetList.Count - 1 do  // Liste von odControlern
  begin
    if odDataSetList[I].od = od then
      odDataSetList[I].od := nil;
    if odDataSetList[I].use_od = od then
      odDataSetList[I].CalcUse;
    Inc(I);
  end;
  TimerOdDestroy.Enabled := False; // im Anschluss gleich die Refrenzen nilen
  TimerOdDestroy.Enabled := True;
end;

procedure TTimerOdDestroy.DoTimer(Sender: TObject);
begin
  TimerOdDestroy.Enabled := False;
  odCheckPointer;  // Referenzen nilen
end;

procedure odCheckPointer;
var
  iod: Tod;
begin
  for iod in odList do
  begin
    if (iod <> nil) and (not iod.HasNotOdPointer) then
    begin
      odProp.CheckPointer(iod); // Eigenschaften eines Objektes prüfen
    end;
  end;
end;

procedure TodProp.CheckPointer(const od: Tod);
var
  Context: TRttiContext;
  RttiType: TRttiType;
  PropInfo: TRttiProperty;
  F: Boolean;
  Attr: TCustomAttribute;
  Value: TValue;
  O: TObject;
  PropValue: String;
begin
  if not Assigned(od) then
    Exit;
  od.HasNotOdPointer := True;

  Context := TRttiContext.Create;
  RttiType := Context.GetType(od.ClassType);

  if Assigned(RttiType) then
  begin
    for PropInfo in RttiType.GetProperties do
    begin
      F := False;
      for Attr in PropInfo.GetAttributes do
      begin
        if Attr is AttrOd then
          F := True;
      end;
      if F then
      begin
        PropValue := '';
        Value := TValue.Empty;
        case PropInfo.PropertyType.TypeKind of
          tkClass:
            begin
              if PropInfo.IsWritable then // betrifft die Eigenschaft eine Objektreferenz?
              begin
                od.HasNotOdPointer := False;
                Value := PropInfo.GetValue(od);
                if (not Value.IsEmpty) then
                begin
                  O := Value.AsObject;
                  try  // wenn das refenzierte Objekt nicht mehr existiert oder ein Zugriff fehl schlägt, dann nilen
                    if (O <> nil) and (O is Tod) and (not odExist(O as Tod)) then
                    begin
                      Value := nil;
                      PropInfo.SetValue(od, Value);
                    end;
                  except
                    Value := nil;
                    PropInfo.SetValue(od, Value);
                  end;
                end;
              end;
            end;
        end;
      end;
    end;
  end;

  Context.Free;
end;

function odExist(od: Tod): Boolean;
begin
  Result := odList.IndexOf(od) >= 0;
end;

[stahli]

Ein prominentes Mitglied der Comunity hat mir zwischenzeitlich im Vertrauen tröstend erklärt, dass ich (zumindest aus seiner Sicht) nicht völlig meschugge bin, sondern lediglich etwas andere Ansätze und Ansprüche habe, als normale Programnmierer... :mrgreen:

Daher mal noch allgemein gefragt:

Wenn "Delphi YE" z.B. eine Möglichkeit böte (rein hypothetisch), Objektreferenzen automatisch auf nil zu setzen, wenn das Zielobjekt aufgelöst wird, würdet Ihr dann diese Neuerung

a) freudig erregt nutzen (und künftig auf ObserverPatterns verzichten)
b) interessiert zur Kenntnis nehmen
c) regungslos zur Kentnis nehmen
d) absichtlich übersehen (und weiter ObserverPatterns schreiben)
e) aufhören, zu programmieren
f) Emba verklagen?

Es wäre doch nett, wenn man eine Objekteigenschaft MyObject.AutoObserver hätte, die man auf True setzen könnte. Alle künftigen Zuweisungen dieses Objektes an Variablen oder Eigenschaften würden "vom Compiler überwacht" (besser gesagt entsprechende automatische Funktionen implementiert), die bei der Auflösung dieses Objektes angestoßen würden und registrierte Referenzen auflösen.

Es wäre letztlich auch eine Observer-Regelung, allerdings nicht im einzelnen Objekt implementiert sondern zentral im Projekt. Das sollte dann sogar auf Variablen anwendbar sein.

Der Compiler müsste dann eine Regestrierung der Beziehung bei der Zuweisung von O1 := O; einbinden.

Variablenreferenzen auf O würden dann direkt in einer Liste verwaltet:

Zitat:

@MyVar1=O
@MyVar2=O
@MyVar3=O

Wird O freigegeben, wird den 3 Variablen nil zugewiesen und sie werden aus der Liste gestrichen.
Wird eine Variable ungültig (Prozeduraussprung), wird sie aus der Liste entfernt.

Eigenschaftsreferenzen wären etwas umfangreicher zu verwalten:

Zitat:

@MyObject1.Ref1=O
@MyObject1.Ref2=O

Die Unterscheidung nach Feldern und Eigenschaften wäre sicher schon aufwendig, aber für Profis doch bestimmt realisierbar.


Ich halte das GRUNDSÄTZLICH für denkbar und möglich (bzw. ich halte es für denkbar, dass das möglich ist).

Jeder Anfänger geht doch erst mal davon aus, dass nach

Delphi-Quellcode:

O := TObject.Create;
O1 := O;
O.Free;

O1 = nil ist.
Man lernt natürlich, dass es nicht so ist, aber vielleicht wäre es Zeit dafür...


Nicht nur die Quellen von DBGrid und DataSource könnten bezüglich der DataSource-Freigabe deutlich schlanker werden...

[DeddyH]

Ich war bislang noch nicht in der Verlegenheit, so etwas zu brauchen, aber es wäre sicherlich in meinen Augen ein nettes Feature, solange es zuverlässig funktioniert.

P.S.:

Zitat:

Zitat von stahli (Beitrag 1089229)

Jeder Anfänger geht doch erst mal davon aus, dass nach

Delphi-Quellcode:

O := TObject.Create;
O1 := O;
O.Free;

O1 = nil ist.

Wieso sollte O1 nil sein, wenn noch nicht einmal O nil ist?

[stahli]

Zitat:

Zitat von DeddyH (Beitrag 1089238)

Ich war bislang noch nicht in der Verlegenheit, so etwas zu brauchen, aber es wäre sicherlich in meinen Augen ein nettes Feature, solange es zuverlässig funktioniert.

P.S.:

Zitat:

Zitat von stahli (Beitrag 1089229)

Jeder Anfänger geht doch erst mal davon aus, dass nach

Delphi-Quellcode:

O := TObject.Create;
O1 := O;
O.Free;

O1 = nil ist.

Wieso sollte O1 nil sein, wenn noch nicht einmal O nil ist?

Ich meinte nur, dass ein Anfänger das im ersten Moment vermuten würde.
Wobei, wenn dieses potentielle Feature O1 nilen würde und O einen ungültigen Zeiger hält, wäre das auch komisch.
Also würde zu dem Wunsch noch dazu gehören, dass O.Free auch automatisch O nilt.

Sofern es zuverlässig funktioniert (das natürlich immer vorausgesetzt) sollte eigentlich niemand Nachteile dadurch haben...

[Thom]

Zitat:

Zitat von stahli (Beitrag 1089229)

a) freudig erregt nutzen (und künftig auf ObserverPatterns verzichten)
b) interessiert zur Kenntnis nehmen
c) regungslos zur Kentnis nehmen
d) absichtlich übersehen (und weiter ObserverPatterns schreiben)
e) aufhören, zu programmieren
f) Emba verklagen?

Ganz eindeutig f und mit dem Schadensersatz daraus zu e übergehen!
Nein - mal im Ernst: Automatismen sind bequem, beherbergen aber auch viele Risiken und Nebenwirkungen.
Keine "Compilermagie" ist immer und überall fehlerfrei. Dafür gibt es viele Beispiele. Um nur mal zwei zu nennen: Zugriff auf COM-Objekte und überladene Methoden/Konstruktoren - davon könnte ich nach der Programmierung des Google Maps Frameworks ein oder besser gleich mehrere Lieder singen... :lol:

Dazu kommt, daß Automatismen die Exe zwangläufig aufblähen, da zusätzlicher Code generiert werden muß. Wenn ich zum Beispiel eine Demo des Frameworks mit Delphi 2010/XE compiliere, ist das Resultat etwa 2 MB groß. Das Ganze zur Kontrolle (ohne irgendwelche Veränderungen!) noch einmal durch den Compiler von Delphi 5 gejagt: Dann bleiben nur noch ca. 400-500kB übrig! Ohne jetzt über Optimierungen diskutieren zu wollen: Der Preis, der für Komfort zu zahlen ist, ist unübersehbar.

Zitat:

Zitat von stahli (Beitrag 1089229)

Jeder Anfänger geht doch erst mal davon aus, dass nach

Delphi-Quellcode:

O := TObject.Create;
O1 := O;
O.Free;

O1 = nil ist.

Na dann sollte er eben Hilfetexte lesen (auch wenn das anstrengend ist, wie viele Hausaufgabenfrager hier im Forum beweisen) und lernen, FreeAndNil() einzusetzen. :wink:

Es gibt viele Lösungsmöglichkeiten, das von Dir beschriebene Problem anzugehen (viele davon wurden schon diskutiert).
Aber mich ausschließlich auf den Compiler verlassen!? Nicht wirklich.

Mal ein Gegenbeispiel für den Aufwand, der entstehen würde:
Eine Objektreferenz wird in einer TObjectList gespeichert. Diese wird aufgelöst, bevor das Objekt freigegeben wird. Und nun!? Jetzt müßte Code generiert werden, wie und ob auf die Objektreferenz überhaupt noch zugegriffen werden kann.

Ich denke, der einfachste und sicherste Weg ist eine saubere Programmierung im Einzelfall - auf für weniger anspruchsvolle Programmierer wie mich... 8-)

[Bummi]

@Thom
:thumb:

[stahli]

Nun habe ich auch noch meinen letzten Sympathisanten verloren... :wink:

Ok, Ihr geht also davon aus, dass eine solche genaralisierte Verfahrensweise nicht stabil genug implementierbar ist.
Wenn das so zutrifft, dann ist das natürlich schade.
Die Programmentwicklung selbst wäre in einigen Bereichen aber sicher einfacher (wenn man sonst Observer einsetzen müsste).

Das Aufblähen der EXE halte ich für nachrangig. Wenn man selbst entsprechende Lösungen realisiert erzeucgen die ja auch Code und ein paar KB mehr machen letzlich auch nix weiter...


Ok, zumindest weiß ich nun mal, wo Ihr Bedenken seht.
Danke für die Rückmeldungen.

[himitsu]

Zitat:

Wenn "Delphi YE" z.B. eine Möglichkeit böte (rein hypothetisch), Objektreferenzen automatisch auf nil zu setzen, wenn das Zielobjekt aufgelöst wird, würdet Ihr dann diese Neuerung

Sowas ist bei Objekten (also Pointern) rein teschnich garnicht möglich, denn

Keiner weiß wo alles Referenzen (Variablen, welche auf das Objekt zeigen) existieren.

Einzige Möglichkeit wäre, wenn der Programmierer irgendwie seine gewünschte Variable "registriert" und somit um das Nil-en bittet.
Solch eine Registrierungsstelle müßtest du aber erstmal implementieren, da es sowas standardmäßig nicht gibt.


Wenn du soein "ähnliches" Verhalten möchtest (nur halt andersrum), dann mußt du Interfaces verwenden.
> Hier wird dann das Objekt (also das hinter dem Interface) erst freigegeben, wenn der Referenzzähler auf 0 steht, also wenn alle Referenzen freigegeben wurden.

[stahli]

Zitat:

Zitat von himitsu (Beitrag 1089447)

Einzige Möglichkeit wäre, wenn der Programmierer irgendwie seine gewünschte Variable "registriert" und somit um das Nil-en bittet.
Solch eine Registrierungsstelle müßtest du aber erstmal implementieren, da es sowas standardmäßig nicht gibt.

Ganz genau das meine ich und würde mir eine Implementierung von Emba wünschen...
(Ich habe das zwar für meine eigenen Objekte implementiert, eine generalisierte Lösung kann ich aber natürlich nicht umsetzen.)

[shmia]

Also wenn ich auch noch meinen Senf dazu geben darf.
Der Blogger Joel Spolsky schreibt auf seiner Website:

Zitat:

Zitat von Joel on Software

The real significant productivity advance we've had in programming has been from languages which manage memory for you automatically. It can be with reference counting or garbage collection; it can be Java, Lisp, Visual Basic (even 1.0), Smalltalk, or any of a number of scripting languages. If your programming language allows you to grab a chunk of memory without thinking about how it's going to be released when you're done with it, you're using a managed-memory language, and you are going to be much more efficient than someone using a language in which you have to explicitly manage memory. Whenever you hear someone bragging about how productive their language is, they're probably getting most of that productivity from the automated memory management, even if they misattribute it.

So grob auf Deutsch übersetzt heisst das, dass man mit Programmiersprachen, die automatisch für die Freigabe von Objekten sorgen einen erheblichen Produktivitätsfortschritt erfährt.
Dieser Aussage würde ich so voll zustimmen.

Ich denke aber auch, dass wenn eine Programmiersprache dies nicht von sich aus unterstützt, es keinen Sinn hat dies nachträglich auf welche Art auch immer zu implantieren.
Das ist sehr schade, aber kaum zu ändern.

Man kann zwar verstärkt Interfaces benützen, aber leider hat dies auch einige gravierende Nachteile:
* Umwandlung Interface -> Objekt nicht möglich (Ausnahme neuere Delphiversionen)
* man ist auf ganz bestimmte Basisklassen beschränkt
* erhöhter Schreibaufwand mit der Folge, das Änderungen am Code deutlich mehr Zeit benötigen

[himitsu]

Zitat:

Zitat von shmia (Beitrag 1089519)

* Umwandlung Interface -> Objekt nicht möglich (Ausnahme neuere Delphiversionen)

Man konnte sich auch früher schon eine entsprechende Methode implementieren.

Delphi-Quellcode:

function TMyClass.GetObject: TObject{oder gar TMyClass};
begin
  Result := Self;
end;

Delphi hat sowas natürlich standardmäßig nicht implementiert, da hinter einem Objekt nicht unbedingt ein Delphi-Objekt liegen muß
und man bei Grenzüberschreitungen von EXE/DLL eh keine Objekte übergeben werden können ... also zumindestens die RTTI paßt dann nicht mehr zusammen.

[Bummi]

Zitat:

Delphi-Quellcode:

function TMyClass.GetObject: TObject{oder gar TMyClass};
begin
  Result := Self;
end;

ääaaehmmm, wie willst das Aufrufen wenn Du keinen Zeiger hast, wenn Du einen hast warum willst Du es aufrufen?:gruebel:

[himitsu]

Nimm

Delphi-Quellcode:

function GetObject: TObject;

mal in dein Interface mit auf :wink:

[Namenloser]

Ich hab mal gerade was zusammengehackt... mit Generics ließe sich da sicher noch mehr machen.

[stahli]

Hi Philip,

das sieht interessant aus!

Allerdings verstehe ich generell die Interfaces (noch) nicht wirklich.
Es wird mit Deiner Lösung jedem Objekt eine Referenzliste hinzugefügt...

Mein Ansatz war eher, dass man normale Objekte verwendet und "der Compiler" auf Wunsch die Referenzen extern verwaltet und ggf. nilt (ohne dass die Objekte eine Referenzliste verwalten müssen).

Meine oben gezeigten Quelltextauszüge machen das ja so (zwar noch etwas ungeschickt und eingeschränkt aber gut funktionsfähig). Die Objekte müssen zur Laufzeit nicht verwalten, von dem sie referenziert werden.

Die Registrierung der Referenz könnte der Compiler vornehmen, sobald eine Objektvariable einer anderen zugewiesen wird.
Dazu könnte eine zentrale Referenzliste verwaltet werden.

Das war eher meine Idee.
Dein Code ist aber beeindruckend (vielleicht verstehe ich den ja irgendwann :wink:)

[Namenloser]

Zitat:

Zitat von stahli (Beitrag 1089561)

Allerdings verstehe ich generell die Interfaces (noch) nicht wirklich.

Das Interface dient hier nur als Behelfslösung, da Records keinen Destructor haben. Klassen haben zwar einen, aber Objekte in Records werden nicht automatisch finalisiert (freigegeben). Interfaces hingegen werden hingegen finalisiert. Bei der Finalisierung wird, wenn der Referenzzähler 0 ist, das Objekt, das hinter dem Interface steht, automatisch freigegeben, also der Destruktor wird aufgerufen. Über diesen Umweg schaffe ich es, dass z.B. für lokale Variablen am Ende der Funktion ihr Eintrag aus der Referenzliste des referenzierten Objekts entfernt wird.

Zitat:

Zitat von stahli (Beitrag 1089561)

Es wird mit Deiner Lösung jedem Objekt eine Referenzliste hinzugefügt...

Mein Ansatz war eher, dass man normale Objekte verwendet und "der Compiler" auf Wunsch die Referenzen extern verwaltet und ggf. nilt (ohne dass die Objekte eine Referenzliste verwalten müssen).

Meine oben gezeigten Quelltextauszüge machen das ja so (zwar noch etwas ungeschickt und eingeschränkt aber gut funktionsfähig). Die Objekte müssen zur Laufzeit nicht verwalten, von dem sie referenziert werden.

Die Registrierung der Referenz könnte der Compiler vornehmen, sobald eine Objektvariable einer anderen zugewiesen wird.
Dazu könnte eine zentrale Referenzliste verwaltet werden.

Habe ich schon verstanden, allerdings müsste der Compiler intern auch pro Objekt eine Liste verwalten. Mit Compiler Magic wäre natürlich die ganze Sache eleganter lösbar, aber da das zur Zeit nicht geht, habe ich halt mal geschaut, wie man der Idee in der Praxis am nähesten kommen kann.

Zitat:

Zitat von stahli (Beitrag 1089561)

Dein Code ist aber beeindruckend (vielleicht verstehe ich den ja irgendwann )

Danke, Danke ;)

[edit]
Übrigens, wenn ich keinen Denkfehler habe, müsste sich mein Code sogar so erweitern lassen, dass Objekte, auf die keine Referenz mehr existiert, automatisch zerstört werden (also so ähnlich wie Interfaces). Durchaus eine spannende Sache...
[/edit]

[BUG]

Ich halte die Idee, die Referenzen aufzulisten, für einen nicht unproblematischen Weg:

• es gibt immer mindestens so viele Referenzen wie Objekte (Speicherlecks mal ausgeschlossen :mrgreen:)
• man stelle sich mal das Nilen der Referenzen in mehrenen Threads vor, da wäre sicher einiges zu beachten

Mein Vorschlag:

(Globale) Events anbieten, welches bei Erstellung und Freigabe eines Objekts aufgerufen werden und eine Referenz erhalten.

Mit Hilfe der Events könnte man dann (wenn man möchte) Listen von Objekten verwalten, um damit die Existenz von Objekten zu prüfen (oder andere coole Sachen machen).
Alle Anderen bekommen dann als Overhead nur, dass während der Erstellung und Freigabe von Objekten geprüft wird, ob die Events gesetzt sind. Das sollte doch im allgemeinen Speicherverwaltungstrubel untergehen :gruebel:

:duck:

[Bummi]

Es ist eine Weile her dass ich mit Interfaces experimentiert habe, hatte aber das von mir gewünschte Verhalten nur mit TInterfacedPersistent, welches für den vorgeschlagenen Ansatz freilich unbrauchbar ist.
Diese automatische Freigabe von Objekten nur weil der Compiler weiß dass ein Objekt nicht mehr benötigt wird, bzw. die Notwendigkeit Objekte dann doch manuell freigeben zu müssen weil die Referenzen global gehalten wurden und aus Events erreichbar waren ... hier dann den Überblick zu behalten was nicht freigegeben werden darf(oder kann) und was freigeben werden muss hat mir die Sache damals dermaßen verleidet, dass ich mich für virtuelle Implementierungen entschieden habe.
Sorry für OT, hat ja eigentlich mit dem Thema nicht wirklich etwas zu tun.

[stahli]

Ich wieder...

Meine Verfahrensweise war ja folgende:
Bei Freigabe eines Objektes untersuche ich alle anderen Objekte per RTTI, ob diese mit einer Objekteigenschaft mein Objekt referenzieren. Dann werden diese betreffenden Objekteigenschaft auf nil gesetzt und danach mein Objekt freigegeben.

Im Grunde funktioniert das (ich arbeite nicht mit Threads) absolut perfekt. ABER es ist extrem langsam.
Ein paar "Optimierungen" musste ich jetzt entfernen, so dass ich die Sache auch nicht beschleunigen kann.

Daher habe ich nun doch eine Observer-Lösung im Auge, möchte das aber auch soweit in meinem App-Framework automatisieren, dass ich nicht zu viel von Hand regeln muss.

Heute Abend schaue ich mir nochmal NamenLozers Lösung an. Vielleicht verstehe ich das ja wenn ich mein Delphi zur Hand habe (so rein theoretisch habe ich keine Chance) und vielleicht lässt sich das ja gut für mich nutzen.

Eine Frage mal grundsätzlich: WANN wird denn eigentlich genau der Referenzzähler eines Objektinterface erhöht und verringert? Macht das der Compiler, wenn ein Objekt an eine Methode übergeben bzw. wenn diese beendet wird und außerdem auch wenn man ObjA := ObjB schreibt? Und das Objekt wird (erst) bei Ref=0 (tatsächlich) freigegeben?
Irgendwie tue ich mich mit den Interfaces immer noch zu schwer... :duck:

[himitsu]

Objekte haben keinen Referenzzähler (standardmäßig), also macht Delphi da auch nichts, beim Kopieren/Freigeben der Objektreferenz.

Das Einzig umständliche ist, daß man interfaces noch "zusätzlich" erstellen/verwalten muß.
Es wäre ja zu schön, wenn man aus einem Objekt (automatisch) ein Interface generieren könnte.

(aber wenn ich mir das grad überlege ... ich glaub das wäre möglich ... muß ich mal sehn, hab eh vor zu versuchen endlich mal einen Precompiler ins Delphi reinzubekommen)

[jaenicke]

Zitat:

Zitat von stahli (Beitrag 1134261)

WANN wird denn eigentlich genau der Referenzzähler eines Objektinterface erhöht und verringert?

Wenn die Variable aus dem Scope läuft (sprich Methodenende, Objektfreigabe des beinhaltenden Objekts, ...) oder einen anderen Wert zugewiesen bekommst, wird _Release aufgerufen.

[himitsu]

Aber nur bei einem "Interface", aber nicht bei Objekten (es sei denn ein Interface wurde angegeben und die eingebetteten Objekte werden über das Interface referenziert/angesprochen)

[stahli]

Also ist es so?

Ich habe 3 Interfaces I1, I2, I3 und erzeuge "in jedes" ein Objekt (O1, O2, O3).

Alle Interfaces haben den Referenzzähler 1.

MyProcedure(I2) erhöht für I2 den Referenzzähler auf 2 bis die Prozedur verlassen wird.

I4 := I2 erhöht wieder für I2 den Referenzzähler auf 2?
I2.Free löst das objekt dann noch nicht auf.
Über I4 wäre es noch ansprechbar?

Aber was wäre wenn man I1 := I3 zuweist? O1 würde aufgelöst und I3 der Referenzzähler erhöht?

Die Objekte selbst sollten dann aber auf keinen Fall händisch aufgelöst werden (also auch nicht aus einer TObjectList mit OwnObjects entfernt werden).

Wenn es einem nicht darum geht, eine Art Mehrfachvererbung zu nutzen (unterschiedliche Objekte mit gleichen Methoden), sondern nur die Referenzierungen sinnvoll behandeln will, dann ist das schon recht kompliziert und aufwendig.

Meine Überlegung war: Wenn für Interfaces die Referenzen vom Compiler überwacht und verwaltet werden, dann sollte das grundsätzlich ja auch für normale Objekte möglich sein. Ok, die müssten noch eine Referenzliste o.ä. erhalten, aber dann würde das automatisiert im Hintergrund ablaufen können.
Philips Lösung sieht ja schon richtig gut aus (ich werde das heute Abend mal ansehen, auch in Bezug auf Objektreferenzen in Propertys). Wenn der Compiler so etwas aber nativ verwurschteln würde wäre m.E. eine der größten Schwächen von Delphi abgestellt. Projekte ließen sich viel leichter realisieren, da ALLE Zugriffe auf aufgelöste Objekte auf NIL zugreifen würden (statt auf zufällige Speicherstellen).

[himitsu]

Man kann Interfaces auch ohne Referenzzählung laufen lassen.
Dann muß man entweder noch Zugriff auf die Objektreferenz haben oder man baut sich eine "gib dich frei"-Methode mit ein, worüber man das Interface dann freigeben kann.
Aber da ist zu beachten, daß bei freigabe alle übrigen Referenzen, sollten noch welche vorhanden sein, zum Absturz führen können, wenn diese feigegeben werden und Delphi dem Interface (welches ja nicht mehr existiert) dieses mitteilen will.

PS: Deswegen speichert man sich manchmal auch als Pointer gecastete Interfacereferenzen, da dort keine automatische Referenzzählung auftritt.


Aber: Nimm dir besser eine TInterfaceList, in dieser hälst du dir eine Referenz und so immer Eine übrig ist, wird das Interface frühestens dann freigegeben, wenn diese InterfaceListe ebenfalls seine Referenzen freigibt.

[Sir Rufo]

@stahli:

Wenn ich dich richtig verstehe, dann willst du für deine Objekte das gleiche Verhalten wie in einer Datenbank bei ForeignKeys.
Die können z.B. bei einer Löschung des Basis-Datensatzes alle verlinkten Datensätze entsprechend aktualisieren und dort die Referenz z.B. auf NULL setzen.

Ein Ansatz dazu wäre folgender:

Delphi-Quellcode:

type
  TTurnier = class
  private
    fPersonID : integer;
    procedure SetPerson( const Value : IPerson );
    function GetPerson : IPerson;
  public
    property Person : IPerson read GetPerson write SetPerson;
  end;

procedure SetPerson( const Value : IPerson );
begin
  fPersonID := Value.ID;
end;

function GetPerson : IPerson;
begin
  Result := GlobaleObjektListe.GetPerson( fPersonID );
end;

Jetzt kannst du bei Bedarf die Person aus der Turnier-Instanz holen und bekommst nur dann eine gülitge Instanz, wenn es diese Person auch noch in der GlobalenObjektListe enthalten ist.

Diese GlobaleObjektListe gibt die Instanzen allerdings nicht frei, sondern vergisst diese einfach nur (IPerson => Interface).
Dann sollte es nicht mehr rumsen und die Referenzen sind sauber.

Und dieses Rumgeeiere mit RTTI kannst du dir sparen ;)