Referenzen auf ungültige Objekte

[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

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