Intelligente Objekte - automatische Freigabe von Referenzen

[himitsu]

Und wie verwaltet corba dann die Referenzen?

[Robotiker]

Zitat von himitsu:

Und wie verwaltet corba dann die Referenzen?

Aus "Common Object Request Broker Architecture" würde ich mal schließen, da gibt einen Broker, der das tut. Ganz ähnlich wie der Vorschlag von Stahli.

Ein Interface entspräche in etwa nur dem, was man in C++ darunter versteht. Da ist ein Interface nur eine Basisklasse, die nur abstrakte Funktionen enthält. Da es in C++ Mehrfachvererbung gibt, kann eine Klasse so auch beliebig viele Interfaces implementieren. Technisch ist so ein Interface nur eine Tabelle von Funktionszeigern.

[Furtbichler]

Ich frage hier nochmals nach:

Wenn man also Objektreferenzen verwendet, die automatisch genullt werden, wenn das referenzierte Objekt freigegeben wird, wie sieht dann so ein Programm aus? Wie sichert man sich gegen spontan auftretende Nil-Referenzen ab? Kann jemand hier mal ein Beispiel nennen?

[stahli]

@Furtbichler:

Ich habe doch oben ein Besipiel beschrieben (wenngleich ich inzwischen ja auch einen anderen Ansatz wählen würde):

Eine Person wird von mehreren Spielerobjekten referenziert (damit alle die selben Daten verwenden bzw. anzeigen).
Wird die Person freigegeben, sollen alle Spielerobjekte erkennen, dass das Personenobjekt nicht mehr existiert (indem sie das Feld auf nil prüfen).
Natürlich sollte vermieden werden, dass das referenzierte Objekt nach dem Prüfen auf nil aufgelöst wird. Aber das ist ja sowiso klar.

Natürlich kann man das anders (besser) regeln, aber WENN man rein mit direkt referenzierten Objekten arbeitet, sollte der Wunsch doch nachvollziehbar sein.

DataSource informiert ja auch DBGrids, über seine Auflösung (über Observer-Pattern). Im Sinne einer einfachen Programmierung und aus Rücksicht auf OOP-Anfänger wäre es nur ganz schön, wenn es dafür einen Automatismus gäbe.

Ich sehe ein, dass das vielleicht nicht ganz einfach zu realisieren ist, aber Deine Nachfrage verstehe ich nicht.

MyDBGrid.DataSource wird ja auch nicht spontan auf nil gesetzt, sondern nur wenn die gebundene DataSource aufgelöst wird.


@Robotiker:
Corba sieht wirklich interessant aus.
http://de.wikipedia.org/wiki/Common_...r_Architecture
http://www.borland.com/de/products/v...ker/index.html
Aber es ist halt wie immer. Ich verstehe das nur zum (Bruch-)Teil.

[Furtbichler]

Zitat von stahli:

Ich habe doch oben ein Besipiel beschrieben ...

Das, was Du beschreibst, ist nicht sicher.

Zitat:

Corba sieht wirklich interessant aus.

Ich dachte, Corba wäre out.

Zitat von BUG:

Aber Absichern vor spontanen Verschwinden bei Zugriff durch mehrere Threads schreit nach Synchronisation

Eben. Aber was läuft im Thread? Irgendwas vom Framework, was mir spontan die Pointer klaut? Das ist Overkill und imho wirklich unsauber.

Ich kann die Motivation von Stahli verstehen, auch der Lösungsansatz bzw. die Idee dahinter von Thom verstehe ich.. Aber notwendig und dann wirklich sauber ist das eben nicht.

Ich würde nie im Leben mit einem System arbeiten, das mir die Immanzenz meiner Objekte nicht sicherstellt. Und genau das wird hier gemacht. Ich muss immer und jederzeit damit rechnen, das mir eine Objektreferenz geklaut wird. Grauselig.

Aber ich schreibe auch keine heterarchischen Systeme wie Stahli. Vermutlich werde ich ähnliche Gehirnakrobatiken anstellen müssen und dann dankbar diesen Thread lesen, wenn ich das mal mache.

Oder ich schreibe keine Heterarchien, stattdessen aber ein Spielermanagement, das mir meine Spieler verwaltet.

[stahli]

Zitat von Furtbichler:

Das, was Du beschreibst, ist nicht sicher.

Versetze Dich halt mal in eine frühere Entwicklungsstufe zurück.
Da ich nicht mit Threads gearbeitet habe und alle Datenobjekte im Speicher verwaltet werden können, funktioniert das letztlich doch zuverlässig.
Inzwischen erkenne ich auch, dass es bessere und vor allem flexiblere Verfahrensweisen gibt. Allerdings bringen die natürlich auch einigen Aufwand und Abstraktion mit sich, so dass man sich "im ersten Moment" eher für einen naheliegenderen Ansatz entscheiden wird. Jedenfalls, wenn man mit diesem noch nicht an bestimmte Grenzen gekommen ist und keine Ausbildung als Programmierer genossen hat.

Zitat von Furtbichler:

Ich dachte, Corba wäre out.

Habe ich auch gelesen. Die Beschreibung des Konzeptes klingt aber sehr nützlich.
Es wäre wohl gut, wenn sich endlich mal ein entsprechendes Konzept durchsetzen würde, mit dem auch Nicht-Profis mit Delphi arbeiten können.
Was soll denn jetzt "in" sein? DataSnap?

Zitat von Furtbichler:

Ich kann die Motivation von Stahli verstehen, auch der Lösungsansatz bzw. die Idee dahinter von Thom verstehe ich.. Aber notwendig und dann wirklich sauber ist das eben nicht.
Ich würde nie im Leben mit einem System arbeiten, das mir die Immanzenz meiner Objekte nicht sicherstellt. Und genau das wird hier gemacht. Ich muss immer und jederzeit damit rechnen, das mir eine Objektreferenz geklaut wird. Grauselig.
Aber ich schreibe auch keine heterarchischen Systeme wie Stahli. Vermutlich werde ich ähnliche Gehirnakrobatiken anstellen müssen und dann dankbar diesen Thread lesen, wenn ich das mal mache.
Oder ich schreibe keine Heterarchien, stattdessen aber ein Spielermanagement, das mir meine Spieler verwaltet.

Ich kann ja kaum den Namen richtig aussprechen, programmiere aber Heterachische Systeme - Wahnsinn.
Wie gesagt, ich habe mit meinen Fähigkeiten (ohne Threads) mein Projekt immer weiter ausgebaut und diverse Wege bestritten. Mit den Objekten konnte ich am flexibelsten arbeiten. Die Klassen habe ich mir teilweise durch einen Experten automatisch erzeugen lassen. In einem Framework binde ich die Objekte automatisiert an die GUI. Dabei ist es hilfreich, wenn die Objekte dauerhaft im Speicher vorliegen.
Das funktioniert eigentlich wunderbar und mit rel. geringem Aufwand (als das Framework funktionierte).

Da ich verschiedene Turniersysteme parallel verwalte und die Spieler/Personen in allen Turniersystemen eingesetzt werden können, wird es inzwischen aber dennoch sehr unübersichtlich. Außerdem möchte ich künftig eine Datenbank oder sogar Client/Server einsetzen. Dann funktioniert es natürlich nicht mehr auf dem bisherigen Weg.

Deshalb plane ich eine Änderung des gesamten Konzeptes, muss damit aber natürlich auch erst meine Erfahrungen machen.

Man geht halt erst einmal den einfachen Weg, bis man erkennt, dass es so nicht weiter geht...

[BUG]

Zitat von Furtbichler:

Wie sichert man sich gegen spontan auftretende Nil-Referenzen ab? Kann jemand hier mal ein Beispiel nennen?

Threads machen sowas natürlich nicht einfacher
Aber Absichern vor spontanen Verschwinden bei Zugriff durch mehrere Threads schreit nach Synchronisation, sollte eigentlich mit einer beliebigen Lösung des Reader-Writer-Problems behandelt werden können.

[Robotiker]

Zitat von Furtbichler:

Ich frage hier nochmals nach:

Wenn man also Objektreferenzen verwendet, die automatisch genullt werden, wenn das referenzierte Objekt freigegeben wird, wie sieht dann so ein Programm aus? Wie sichert man sich gegen spontan auftretende Nil-Referenzen ab? Kann jemand hier mal ein Beispiel nennen?

Wie das aussehen kann, kannst du in der Doku der vom C++ Builder verwendeten Bibliothek nachlesen:
http://www.boost.org/doc/libs/1_49_0.../smart_ptr.htm

Ein weak_ptr hat z.B. eine Memberfunktion expired() mit der man prüfen kann, ob er noch gültig ist.

Greift man auf einen ungültigen Pointer zu gilt

Zitat:

When the last shared_ptr to the object goes away and the object is deleted, the attempt to obtain a shared_ptr from the weak_ptr instances that refer to the deleted object will fail: the constructor will throw an exception of type boost::bad_weak_ptr, and weak_ptr::lock will return an empty shared_ptr.

Zitat von Furtbichler:

Zitat:

Corba sieht wirklich interessant aus.

Ich dachte, Corba wäre out.

Es ist gewissermaßen unter seinem Eigengewicht zusammengebrochen.

Zitat von BUG:

Aber Absichern vor spontanen Verschwinden bei Zugriff durch mehrere Threads schreit nach Synchronisation, sollte eigentlich mit einer beliebigen Lösung des Reader-Writer-Problems behandelt werden können.

Ja, siehe
http://www.boost.org/doc/libs/1_49_0...m#ThreadSafety

Zitat von stahli:

Versetze Dich halt mal in eine frühere Entwicklungsstufe zurück.

Die Themen Corba und Smartpointer waren zu Zeiten des C++ Builder 3/4/5 sehr modern.

Corba ist in der Versenkung verschwunden, die Smartpointer sind heute ISO-Standard.