spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Öffentliche Init-Methoden sind eigentlich nie eine gute Idee. Private sind ganz Ok, weil man die dann von den verschiedenen Konstruktoren aufrufen kann.

Grundsätzlich sollte ein Objekte nach dem Aufruf des Konstruktors komplett initialisiert und funktionsbereit sein. Also: Mach jegliche nötige Initialisierung im Konstruktor, respektive in ausgelagerten privaten Init-Methoden.

Warum öffentliche Init-Methoden schlecht sind: Ganz einfach. Der Benutzer wird ganz bestimmt vergessen diese aufzurufen. Oder aber es passiert "zufällig" (refactoring, code moving etc.).

Zitat von »Blue Phoenix«

Einige Klassen (und damit deren ableitungen) haben neben der Funktion um Grafische dinge zu initilisieren noch eine initialize Methode um nicht Grafische dinge zu initialisieren, ich tu mich nun etwas schwer damit zu verstehen, wann genau es sinnvoll ist diese initialize Methode zu verwenden anstelle das ganze einfach über denn Konstruktor zu machen.

Die Tatsache, dass du dir da mit dem Verständnis schwer tust, zeigt, dass du genau auf dem richtigen Weg bist, denn da gibt es nichts zu verstehen. Die ordentliche Lösung ist, das über den Konstruktor zu machen...

Zitat von »Blue Phoenix«

Gibt es da irgendwelche Regeln, Weisheiten, Guidlines [...]

Jap: Init Methoden sind Mist, genau dafür gibts Konstruktoren...

Alles was einen Fehler erzeugen kann, gehört in eine Init-Methode. Warum? Weil der Konstruktor trotzdem ausgeführt wird und kein Rückgabewert besitzt. Was gibt es schlimmeres als gar kein Objekt im Speicher? Genau! Ein beschädigtes Objekt im Speicher das nicht funktioniert.
Btw kann es auch sein, dass man ein Objekt noch gar nicht komplett beim Konstruktoraufruf initialisieren möchte.

Prinzipell: Benutze den Konstruktor um elementare Datentypen, Zeiger oder (ich nenne es mal "solide") Objekte zu initialisieren. Alles andere gehört in eine Init-Methode.

Berichtigt mich, wenn ich falsch liege.

lg René

Und woher kommt das Objekt, auf dem du deine Init Methode aufrufen willst? Und in welchem Zustand befindet es ich bis zum Aufruf der Init Methode? Und was passiert wenn der Benutzer vergisst, die Init Method aufzurufen? Und Wie stellst du sicher, dass der Benutzer nicht darauf vergisst? Und welche Rolle spielt in diesem Modell mit der Init Methode der Konstrutor?

Zitat von »Renegade123«

Alles was einen Fehler erzeugen kann, gehört in eine Init-Methode. Warum?

Gute Frage, frag ich mich auch grad...

Zitat von »Renegade123«

Was gibt es schlimmeres als gar kein Objekt im Speicher? Genau! Ein beschädigtes Objekt im Speicher das nicht funktioniert.

Inwiefern unterscheidet sich ein Objekt, das zwar erzeugt wurde, aber dessen Init Methode noch nicht aufgerufen wurde von einem "beschädigten Objekt im Speicher das nicht funktioniert"?

Zitat von »Renegade123«

Btw kann es auch sein, dass man ein Objekt noch gar nicht komplett beim Konstruktoraufruf initialisieren möchte.

Hast du schnell ein Beispiel für mich, wann man sowas möchte?

Klar. Ein AudioSystem, ein VideoSystem oder ein anders großes System was Subsysteme inne hat.

Hast du das Buch Game Coding Complete von Mike McShaffry und David "Rez" Graham? Wenn ja, bei mir ist es Seite 130. Kleiner Auszug: "It turns out that C++ Constructors are horrible at initializing game objects especially if you declare your C++ objects globally."

Warum sagt Mike McShaffry das?
1. Systeme wie AudioSystem oder VideoSystem sind komplizierte Systeme die Untersysteme beinhalten können.
2. Es geht nicht um Ausnahme Behandlung, sondern um Wiederherstellungs Mechanismen. Das bedeutet, man soll dem Spieler eine Chance geben, zu handeln, wenn Fehler auftreten.
3. Du hast keine Kontrolle darüber, in welcher Reihenfolge globale Variablen intialisiert werden.
4. Konstruktoren haben keinen Rückgabewert und es kann sein, das man den Fehler auf hässliche Weise suchen muss.
5. Fehler möchte man womöglich mit einer DialogBox anzeigen. Ob diese angezeigt wird, kann abhängig davon sein ob die Systeme Video, User Interface, Data Files welche z.B. Buttongrafiken oder Schrift darstellen, richtig erzeugt wurden. Was ist, wenn diese Grafiken beschädigt sind und keine Buttons angezeigt werden können?

Ich hoffe ich konnte es einigermaßen verständlich übersetzen. Er behandelt im Buch einige Seiten dieses Thema und das sind nur ein paar Stichpunkte dazu.

PS: Warum bist du so stachelig ?

lg René

Globale Variablen sind ohnehin Müll. Deine Voraussetzung ist also flawed.
Unbekannte Initialisierungsreihenfolge ist sogar noch schlimmer als globale Variablen. Wer sowas baut, der hat es verdient, dass ihm das alles um die Ohren fliegt.

Was hälst du von globalen Zeigern?
McShaffry führt auch dann recht schnell auf, dass globale Zeiger besser sind als globale Variablen. Dabei meint er, man soll diese Initializieren, wenn man "good and ready" ist.

Ja, ich sage doch unbekannte Initialisierungsreihenfolge ist schlecht. Deshalb ja eben die Init-Methode. Hast du richtig gelesen?
Wir wissen nicht in welcher Reihenfolge der Compiler globale Objekte instanziiert. Manchmal tut er es in der geschriebenen Reihenfolge und manchmal nicht.

PS: Globale Variablen sind ohnehin Müll. Ich habe mittlerweile das Gefühl, dass wenn andere Programmierer global lesen, den hier bekommen ->
Global-isierung

lg René

Zitat von »Renegade123«

PS: Warum bist du so stachelig ?

Wahrscheinlich weil du Müll erzählst.

Zitat von »Renegade123«

McShaffry führt auch dann recht schnell auf, dass globale Zeiger besser sind als globale Variablen. Dabei meint er, man soll diese Initializieren, wenn man "good and ready" ist.

Eigentlich wollte ich mir das Buch kaufen. Jetzt hast du mich umgestimmt...

Zitat von »Renegade123«

Klar. Ein AudioSystem, ein VideoSystem oder ein anders großes System was Subsysteme inne hat.

Und wieso?

Zitat von »Renegade123«

Hast du das Buch Game Coding Complete von Mike McShaffry und David "Rez" Graham?

Nein und wie es aussieht hab ich mir den Platz im Bücherregal auch besser aufgehoben...

Zitat von »Renegade123«

Warum sagt Mike McShaffry das?

Weil er C++ nicht verstanden hat!?

Zitat von »Renegade123«

1. Systeme wie AudioSystem oder VideoSystem sind komplizierte Systeme die Untersysteme beinhalten können.

Da kann ich nur zustimmen. Ich seh aber nicht, was du mir damit sagen willst bzw. wieso Konstrukturen dabei ein Problem darstellen würden.

Zitat von »Renegade123«

2. Es geht nicht um Ausnahme Behandlung, sondern um Wiederherstellungs Mechanismen. Das bedeutet, man soll dem Spieler eine Chance geben, zu handeln, wenn Fehler auftreten.

Ok, ich versteh aber leider nicht, inwiefern Konstrukturen diesem Ziel im Wege sein sollen.

Zitat von »Renegade123«

3. Du hast keine Kontrolle darüber, in welcher Reihenfolge globale Variablen intialisiert werden.

Das stimmt nur bedingt. Die Initialisierungsreihenfolge globaler Objekte in der selben Übersetzungseinheit (im selben .cpp File) ist wohldefiniert. Modulübergreifend kann man Funktionen benutzen, die eine Referenz auf eine lokale statische Variable returnen um dieses Problem elegant zu lösen. Sofern man bei derlei Konstrukten überhaupt von "elegant" sprechen kann...

Zitat von »Renegade123«

4. Konstruktoren haben keinen Rückgabewert und es kann sein, das man den Fehler auf hässliche Weise suchen muss.

Was hat das eine mit dem anderen zu tun?

Zitat von »Renegade123«

5. Fehler möchte man womöglich mit einer DialogBox anzeigen. Ob diese angezeigt wird, kann abhängig davon sein ob die Systeme Video, User Interface, Data Files welche z.B. Buttongrafiken oder Schrift darstellen, richtig erzeugt wurden. Was ist, wenn diese Grafiken beschädigt sind und keine Buttons angezeigt werden können?

Alles schön und gut, ich seh leider trotzdem nicht, welches Problem Init Methoden dabei genau lösen sollen.

Zitat von »Renegade123«

PS: Warum bist du so stachelig ?

Sry wenn das so rüberkommt, ich hoffe du fühlst dich nicht angegriffen, denn das ist nicht meine Absicht. Ich versuch nur manchmal, die Leute dazu zu provozieren, sich selbst die Antwort zu geben, denn zumindest ich persönlich find es sehr viel befriedigender, zu einer Erkenntnis zu gelangen, als von einer zu lesen.