|
Referenzen auf ungültige Objekte
(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:
Das Objekt O wird in eine Liste aufgenommen. Wird das Objekt freigegeben, wird es aus der Liste entfernt.
RegisterValidObject(O)
Dann könnte man mit
Delphi-Quellcode:
bzw.
IsValidObject(X.MyO)
Delphi-Quellcode:
prüfen, ob das Objekt noch gültig (noch in der Kontroll-Liste enthalten) ist.
IsValidObject(MyO)
Das wäre so ähnlich zu sehen, wie
Delphi-Quellcode:
, wobei nicht nur auf nil geprüft wird, sondern auf die Existenz des referenzierten Objektes.
Assigned(X.MyO)
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? |
AW: Referenzen auf ungültige Objekte
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. |
AW: Referenzen auf ungültige Objekte
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
mfg Christian |
AW: Referenzen auf ungültige Objekte
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.
|
AW: Referenzen auf ungültige Objekte
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) |
AW: Referenzen auf ungültige Objekte
@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. |
AW: Referenzen auf ungültige Objekte
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; |
AW: Referenzen auf ungültige Objekte
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 |
AW: Referenzen auf ungültige Objekte
Zitat:
Zitat:
In allen existierenden Objekten nach einer Referenz zu suchen, halte ich für einen Designfehler. |
AW: Referenzen auf ungültige Objekte
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
- 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 |
AW: Referenzen auf ungültige Objekte
@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.
|
AW: Referenzen auf ungültige Objekte
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:
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:
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:
Deshalb wird dort die Referenz auf eine Person genutzt. Zitat:
Zitat:
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:
|
AW: Referenzen auf ungültige Objekte
Zitat:
Zitat:
Zitat:
Zitat:
 Decorator-Pattern an.Zitat:
Zitat:
Zitat:
Zitat:
- 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 |
AW: Referenzen auf ungültige Objekte
Zitat:
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:
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:
Zitat:
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... |
AW: Referenzen auf ungültige Objekte
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. |
AW: Referenzen auf ungültige Objekte
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; |
AW: Referenzen auf ungültige Objekte
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:
Wird eine Variable ungültig (Prozeduraussprung), wird sie aus der Liste entfernt. Eigenschaftsreferenzen wären etwas umfangreicher zu verwalten: Zitat:
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:
O1 = nil ist.
O := TObject.Create;
O1 := O; O.Free; 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... |
AW: Referenzen auf ungültige Objekte
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:
|
AW: Referenzen auf ungültige Objekte
Zitat:
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... |
AW: Referenzen auf ungültige Objekte
Zitat:
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:
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-) |
AW: Referenzen auf ungültige Objekte
@Thom
:thumb: |
AW: Referenzen auf ungültige Objekte
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. |
AW: Referenzen auf ungültige Objekte
Zitat:
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. |
AW: Referenzen auf ungültige Objekte
Zitat:
(Ich habe das zwar für meine eigenen Objekte implementiert, eine generalisierte Lösung kann ich aber natürlich nicht umsetzen.) |
AW: Referenzen auf ungültige Objekte
Also wenn ich auch noch meinen Senf dazu geben darf.
Der Blogger Joel Spolsky schreibt auf seiner Website:Zitat:
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 |
AW: Referenzen auf ungültige Objekte
Zitat:
Delphi-Quellcode:
Delphi hat sowas natürlich standardmäßig nicht implementiert, da hinter einem Objekt nicht unbedingt ein Delphi-Objekt liegen muß
function TMyClass.GetObject: TObject{oder gar TMyClass};
begin Result := Self; end; 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. |
AW: Referenzen auf ungültige Objekte
Zitat:
|
AW: Referenzen auf ungültige Objekte
Nimm
Delphi-Quellcode:
mal in dein Interface mit auf :wink:
function GetObject: TObject;
|
AW: Referenzen auf ungültige Objekte
Liste der Anhänge anzeigen (Anzahl: 1)
Ich hab mal gerade was zusammengehackt... mit Generics ließe sich da sicher noch mehr machen.
|
AW: Referenzen auf ungültige Objekte
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:) |
AW: Referenzen auf ungültige Objekte
Zitat:
Zitat:
Zitat:
[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] |
AW: Referenzen auf ungültige Objekte
Ich halte die Idee, die Referenzen aufzulisten, für einen nicht unproblematischen Weg:
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: |
AW: Referenzen auf ungültige Objekte
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. |
AW: Referenzen auf ungültige Objekte
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: |
AW: Referenzen auf ungültige Objekte
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) |
AW: Referenzen auf ungültige Objekte
Zitat:
|
AW: Referenzen auf ungültige Objekte
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)
|
AW: Referenzen auf ungültige Objekte
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). |
AW: Referenzen auf ungültige Objekte
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. |
AW: Referenzen auf ungültige Objekte
@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:
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.
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; 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 ;) |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 09:47 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz