Referenzen auf ungültige Objekte

[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

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

[Namenloser]

Zitat von stahli:

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

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

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 )
• 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