Referenzen auf ungültige Objekte

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

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

[himitsu]

Nimm function GetObject: TObject; mal in dein Interface mit auf

[Thom]

Zitat von Thom:

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.

[...]

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

Ein knappes Jahr später kann ich dazu nur noch sagen:

Du hast vollkommen Recht, stahli: Es gibt durchaus sinnvolle Anwendungsmöglichkeiten für ein derartiges Verhalten und ich habe inzwischen auch Situationen gefunden, in denen das sogar zwingend notwendig ist.
Inzwischen funktioniert es auch:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  o, o1: INotify;
begin
  o:=TNotifyObject.Create;
  o1:=o;
  o.Free;
  if not assigned(o) and not assigned(o1)
    then ShowMessage('Toll!')
    else ShowMessage('War wohl nichts...');
end;

Natürlich erscheint die erste Meldung.