Referenzen auf ungültige Objekte

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

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 von stahli:

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 von 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 von stahli:

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 von stahli:

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

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 von stahli:

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.

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

[Bummi]

@Thom

[stahli]

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

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 von himitsu:

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 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 von shmia:

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