Designfrage: Mehrfachvererbung / Interfaces

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.

314159265358979

volkard schrieb:

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

Dann kann ich dir leider nicht helfen. Ist in etwa dasselbe wie RAII vs. Java try-catch-finally-close.

volkard schrieb:

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.

Es ist einfach nicht die Aufgabe eines Objektes, seine eigene Lebenszeit zu managen. Das kann es auch gar nicht, da es auch nicht weiß, wie (Stack/Heap) es erstellt wurde. Das kann nur der Besitzer - und das ist der shared_ptr. Solche Objekte können also nur auf dem Heap angelegt werden.

cdtgfvhbj schrieb:

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.

Haha, sehr witzig. Ein Paradebeispiel für intrusives Refcounting ist Irrlicht. Sowas ekelhaftes und grundsätzlich falsches sieht man selten. Aber ich weiß doch worums euch wieder mal geht: Mich zu schikanieren. Ihr wisst selbst ganz genau, dass ich Recht habe. Und weil ich euch nicht nochmal für euch hinschreibe, was ihr eh schon wisst, behauptet ihr einfach, ich hätte keine Argumente. Stellt euch nicht so dumm.

314159265358979 schrieb:

cdtgfvhbj schrieb:

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.

Haha, sehr witzig. Ein Paradebeispiel für intrusives Refcounting ist Irrlicht. Sowas ekelhaftes und grundsätzlich falsches sieht man selten.

Keine Ahung was Irrlicht macht, aber scheint wohl kein Paradebeispiel zu sein.

Aber ich weiß doch worums euch wieder mal geht: Mich zu schikanieren. Ihr wisst selbst ganz genau, dass ich Recht habe. Und weil ich euch nicht nochmal für euch hinschreibe, was ihr eh schon wisst, behauptet ihr einfach, ich hätte keine Argumente. Stellt euch nicht so dumm.

Genau.

hustbaer schrieb:

Glaub was du willst.

dot

314159265358979 schrieb:

volkard schrieb:

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

Dann kann ich dir leider nicht helfen. Ist in etwa dasselbe wie RAII vs. Java try-catch-finally-close.

Überhaupt nicht. RAII geht mit intrusivem Ref Counting wunderbar Hand in Hand, verwend ich in Zusammenhang mit COM die ganze Zeit. Abgesehen davon hast du mit shared_ptr grundsätzlich das Problem von wegen wo der Counter angelegt wird, der damit verbundene Overhead fällt bei intrusivem Ref Counting nicht an, bei shared_ptr lässt er sich nur teilweise vermeiden wenn man make_shared benutzt und die Implementierung schlau ist...

hustbaer

@dot
Vergiss es, Pi hat wieder mal seinen "ICH HAB RECHT UND IHR SEID SO GEMEIN!!!!111elf" Overdrive aktiviert. (*)

Das wird hier nix mehr.

*: Ich frage mich wie lange es dauert bis ihm der endgültig das Hirn rausbrennt.

314159265358979

Bei shared_ptr lässt er sich immer vermeiden, vorausgesetzt, man hat eine ordentliche Implementierung. Die std-Implementierung gibt da zu wenige Garantien.