Designfrage: Mehrfachvererbung / Interfaces

dot

Ein Artikel den ich dir sehr zu Herzen legen würde: http://scientificninja.com/blog/write-games-not-engines

Glaub mir, ich weiß warum

Baldur

Hm, man könnte das ganze auch als Framework bezeichnen, man fängt ja auch nicht bei jedem Spiel komplett von null an und schreibt alle Klassen für Scenes, Pointer-Handling, etc neu
Aktuell ist es für mich eine Spielerei, um ein paar Dinge auszuprobieren. Obs tatsächlich mal ein Spiel wird, ist erst einmal Nebensache.

@PI
Was würdest du stattdessen vorschlagen? Ich bin da durchaus für Ideen offen. Da das ganze ein privates Projekt ist, hindert mich ja auch niemand daran, alles über den Haufen zu werfen und neu/besser zu implementieren

Ich hab allerdings anfangs schon diese Variante gegen die Verwenung von Helfern wie shared_ptr abgewogen und fand diese Variante angenehmer. Ich muss allerdings auch zugeben, daß ich bisher nur diese beiden Mechanismen kenne.

dot

shared_ptr ist wieder nur Reference Counting. Meiner Erfahrung nach braucht man Reference Counting äußerst selten (praktisch nie). Überleg dir stattdessen, wie die Besitzverhältnisse wirklich aussehen und mach die Objekte dann direkt zu Membern oder lokalen Objekten. Immer ein guter Freund ist std::unique_ptr.
Scope ist nichts wogegen man kämpfen muss, sondern potentiell einer der stärksten Verbündeten die ein Programmierer hat...

314159265358979 schrieb:

Dein Designfehler ist das intrusive Referenzzählen.

was ist daran schlecht?

Baldur

So ganz einfach ist es auch nicht, zu sagen daß Objekte nur von ihren Besitzern zerstört werden sollen.

Wenn ich zum Beispiel nun in meinem Spiel ein Dialogfeld anzeige, kann man natürlich sagen, das Dialogfeld gehört dem Application Objekt und soll von diesem gelöscht werden, wenn ich es schließe. Aber wie sieht es mit den Buttons oder Textfeldern auf dem Dialogfeld aus? Eigentlich möchte ich doch lieber, daß die mit dem Dialogfeld direkt mit gelöscht werden, und mir keine Liste mit Objekten merken, bzw. wann die gelöscht werden dürfen.
Oder ich will einen Scene-Wechsel mit Hilfe einer Transition durchführen, dann möchte ich, daß die Transition mein altes Scene-Objekt löschen kann, sobald die Transition beendet ist.

Und natürlich gibt es Fälle wie den obigen, daß z.B. ein TouchHandler ein Objekt behalten kann, was sonst bereits gelöscht wäre.

Ist natürlich kein Allheilmittel und hat auch seine eigenen Nachteile, auf die man achten muss. Für die aktuelle Aufgabe erschien es mir aber bisher die geeigneteste Lösung zu sein.

Ist jetzt nicht so, daß ich noch kein Spiel geschrieben hätte, welches diese Art von Speichermanagement benutzt, und bisher hat es eigentlich immer recht zuverlässig funktioniert

314159265358979

cdtgfvhbj schrieb:

was ist daran schlecht?

Was ist daran gut? Intrusives refcounting hat nur Nachteile gegenüber shared_ptr. Der gröbste dürfte wohl sein, dass es nicht automatisch funktioniert.

dot

Baldur schrieb:

Wenn ich zum Beispiel nun in meinem Spiel ein Dialogfeld anzeige, kann man natürlich sagen, das Dialogfeld gehört dem Application Objekt und soll von diesem gelöscht werden, wenn ich es schließe.

Mit anderen Worten: Du möchtest dass das Dialogfeld ein Member der Application ist...

Baldur schrieb:

Aber wie sieht es mit den Buttons oder Textfeldern auf dem Dialogfeld aus? Eigentlich möchte ich doch lieber, daß die mit dem Dialogfeld direkt mit gelöscht werden, und mir keine Liste mit Objekten merken, bzw. wann die gelöscht werden dürfen.

Mit anderen Worten: Du möchtest dass die Buttons und Textfelder Member des Dialogfeldes sind...

Baldur schrieb:

Oder ich will einen Scene-Wechsel mit Hilfe einer Transition durchführen, dann möchte ich, daß die Transition mein altes Scene-Objekt löschen kann, sobald die Transition beendet ist.

Lässt sich z.B. über std::unique_ptr machen. Was du da beschreibst, klingt mir eher nach Ownership-Transfer und nicht nach shared Ownership...

Baldur schrieb:

Und natürlich gibt es Fälle wie den obigen, daß z.B. ein TouchHandler ein Objekt behalten kann, was sonst bereits gelöscht wäre.

Wieso genau muss der TouchHandler das so machen?

hustbaer

void retain();

Kommst du von Objective-C?

Gibt es noch eine Möglichkeit, auf die ich noch nicht gekommen bin?

shared_ptr , und die Engine merkt sich dann nen weak_ptr auf das Objekt das Input gecaptured hat. Wenn das Objekt in der Zwischenzeit gelöscht wurde kommt bei weak_ptr::lock dann ein leerer shared_ptr zurück.
Jedes Objekt hat nen "Deleting" Event, und die Engine hängt sich auf den "Deleting" Event des Input-Empfänger Objekts drauf.
Globale Objekt-Registry die jedem Objekt eine (nicht recyclebare) ID zuordnet (mit 64 Bit IDs sollte es ausreichend lange dauern bis die IDs "ausgehen").

hustbaer

314159265358979 schrieb:

cdtgfvhbj schrieb:

was ist daran schlecht?

Was ist daran gut? Intrusives refcounting hat nur Nachteile gegenüber shared_ptr. Der gröbste dürfte wohl sein, dass es nicht automatisch funktioniert.

Und wenn du weniger dogmatischen Blödsinn schreiben würdest, würden wir dich vielleicht irgendwann ernst nehmen.

314159265358979

Und wenn ich Recht habe?

Tyrdal

Dann hab das mal und wir können weiterreden.

Baldur

Wenn du Recht hast wäre es nett das auch zu begründen. Nur mit einem "das ist Müll" kann man leider wenig anfangen.

hustbaer schrieb:

Kommst du von Objective-C?

Zum Glück nicht, aber ich arbeite derzeit mit einem Game-Framework, das von Objective C portiert wurde und habe gewohnheitsmäßig die Benamung beibehalten.

Evtl schau ich mir die shared_ptr nochmal an, nachdem ich die Input-Handling Geschichte fertig habe. Wie gesagt, ich hatte die Überlegung anfangs schon gemacht, gerade weil shared_ptr automatisch funktioniert, müsste mich aber auch erst mal richtig damit auseinandersetzen, da ich z.B. nicht weiß wie das z.B. mit Vererbung klappt. Zudem war ich mir auch nicht sicher, ob ich die Library unter Android Native zur Verfügung habe, wofür ich das hauptsächlich schreiben will.

hustbaer

314159265358979 schrieb:

Und wenn ich Recht habe?

Wenn du Recht hättest, was in diesem Fall (wieder mal) nicht so ist, dann wäre es dennoch sinnloser Blödsinn einfach nur dogmatisch Dinge zu behaupten.
Wir halten dich nämlich tendenziell eher für doof und lästig anstatt dir Dinge die du einfach nur behauptest einfach so zu glauben.
(Also ich kann natürlich nur für mich sprechen, hab aber so das Gefühl als ob ich da nicht ganz allein wäre)

314159265358979

Widerleg halt meine Aussage, ansonsten hab ich eben Recht. :p

hustbaer

Glaub was du willst.

lass TouchReceiver auch von SharedObject ableiten,

http://msdn.microsoft.com/en-us/library/wcz57btd.aspx

314159265358979 schrieb:

cdtgfvhbj schrieb:

was ist daran schlecht?

Was ist daran gut? Intrusives refcounting hat nur Nachteile gegenüber shared_ptr. Der gröbste dürfte wohl sein, dass es nicht automatisch funktioniert.

Wenn man glaubt, dass Intrusive Pointer durch Shared Poniter austauschbar sind, hat man wohl keine guten Argumente und, wie hustbaer schon sagte, nichts verstanden.

314159265358979

Intrusives Refcounting ist nicht nur durch shared_ptr austauschbar, mit shared_ptr kanns auch weak_ptr geben. Und wie schon gesagt ist manuelles Refcounting absoluter Käse. Ein release vergisst man schnell mal und bei Exception Safety brauchen wir gar nicht erst anfangen.

volkard

314159265358979 schrieb:

Intrusives Refcounting ist nicht nur durch shared_ptr austauschbar, mit shared_ptr kanns auch weak_ptr geben. Und wie schon gesagt ist manuelles Refcounting absoluter Käse. Ein release vergisst man schnell mal und bei Exception Safety brauchen wir gar nicht erst anfangen.

Also sagste nur "wenn man es selber macht, muß man ein wenig aufpassen.
Kein Argument für mich.

Haste technische Aspekte, wie daß die Basisklasse SharedObject grundsätzlich einen virtuellen Destruktoraufruf feiern muß, während shared pointers in manchen Fällen ohne auskommen? Naja, war ein Versuch, trifft hier wohl nicht zu.

Saug Dir mal was aus den Fingern, warum shared pointers grundsätzlich besser sind.

314159265358979 schrieb:

Intrusives Refcounting ist nicht nur durch shared_ptr austauschbar, mit shared_ptr kanns auch weak_ptr geben. Und wie schon gesagt ist manuelles Refcounting absoluter Käse. Ein release vergisst man schnell mal und bei Exception Safety brauchen wir gar nicht erst anfangen.

Intrusive Pointer zählen auch selber. Du hast keine Ahnung, wie man das alles richtig einsetzt.

Hier mal was ganz einfaches http://www.codeproject.com/Articles/8394/Smart-Pointers-to-boost-your-code
Google mal ein bisschen, vor du weiter Müll von dir gibst.