spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Lass es weg.
Gib zig Bibliotheken wo du dir das a) einfacher zusammenbauen kannst und b) dir selbst beibringen kannst.
Zumal ich finde, dass das Kapitel nicht so ist, was man hätte herausholen können.
Die Entscheidung ist letztlich bei dir.

Singletons waren aber in 8, wenn ich mich nicht irre...? Bin jetzt zu faul zum Gucken.

MfG
Check

Das musst du selbst entscheiden, es kommt ganz darauf an, was dich interessiert bzw. für was du programmieren möchtest. Du brauchst nicht unbedingt Grundlagen in der Windowsprogrammierung, um mit einigen Frameworks arbeiten zu können, jedoch schadet es nie, zu verstehen, was im Hintergrund passiert. Außerdem ist es nicht schlecht, Funktionen der WinAPI verstehen und nutzen zu können, wenn man explizit für Windows programmiert (muss aber nicht sein, da es Alternativen gibt).

Zitat von »dot«

Früher oder später findet jeder raus warum man um Singletons einen großen Bogen machen sollte

Das finde ich ein bisschen pessimistisch.
Ich habe hier einen Firefox, klicke auf Hilfe->"Über Firefox", da kommt so n Fenster mit ner Version. Ich mach das nochmal, und es erscheint kein zweites Fenster. Das ist doch mal ein klassischer Anwendungsfall für ein Singleton.
Oder eine Konfigurationsklasse, die bei der ersten Verwendung initialisiert wird, und später per Singeton von überall aus verwendet werden kann, ohne jedesmal neu initialisiert werden zu müssen, und ohne alle Interfaces aufzublähen, weil Pointer weitergegeben werden müssen. Und vor allem: ohne dass irgend ein Progger (und sei ich es selbst in einem Anfall geistiger Umnachtung) eine zweite Konfigurationsklasse erzeugt, lustig Werte ändert, und sich wundert, warum sich die Änderungen nur auf einen Teil des Codes auswirkten. (Vorausgesetzt ich weil genau *eine* Konfigurationsklasse in meinem Programm verwenden)

Ich mach z.T. sogar solche Sachen:


So kann ich ANTI_ZAP_RANGE wie ein define verwenden.
Ich könnte auch jedesmal CConfig::instance()->get_antizap_range() schreiben, aber dann werden die Ifs immer so lang und unleserlich....
Ein Herz für die Singletons!

Zitat von »spark«

Zitat von »dot«

Früher oder später findet jeder raus warum man um Singletons einen großen Bogen machen sollte

Das finde ich ein bisschen pessimistisch.
Ich habe hier einen Firefox, klicke auf Hilfe->"Über Firefox", da kommt so n Fenster mit ner Version. Ich mach das nochmal, und es erscheint kein zweites Fenster. Das ist doch mal ein klassischer Anwendungsfall für ein Singleton.

Nein, falsch.

Auch das Beispiel mit Deiner Config ist ganz schlecht. Man stelle sich nun vor, dass die Anwendung plötzlich Plugins bekommen soll und jedes Plugin seine eigene Config braucht. Schon geht das Theater wieder los. Singletons sind für diese Config absolut nicht die korrekte Lösung!
Das einzige Argument, was ich bei Dir sehe, welches angeblich FÜR Configs als Singleton spricht, ist Faulheit die Interfaces korrekt zu erweitern und zu übergeben. Das ist nicht die Idee hinter einem Singleton. Klassen müssen dann Singletons sein, wenn es auf gar keinen Fall mehr als eine Instanz geben DARF. Bei Configs sehe ich das aber überhaupt nicht. Genauso gut ließe sich das über Dependency Injection *sauber* lösen und es ist absolut nicht notwendig, dass nur eine einzige Config existieren dürfte.

Zitat von »spark«

Oder eine Konfigurationsklasse, die bei der ersten Verwendung initialisiert wird, und später per Singeton von überall aus verwendet werden kann, ohne jedesmal neu initialisiert werden zu müssen, und ohne alle Interfaces aufzublähen, weil Pointer weitergegeben werden müssen. Und vor allem: ohne dass irgend ein Progger (und sei ich es selbst in einem Anfall geistiger Umnachtung) eine zweite Konfigurationsklasse erzeugt, lustig Werte ändert, und sich wundert, warum sich die Änderungen nur auf einen Teil des Codes auswirkten.

Du beschreibst eigentlich einfach ein globales Objekt, und fügst hinten mal kurz eine Eigenschaft ein, die zufällig vom Singleton kommt, ohne dass sie hier Sinn macht. Mal ehrlich, wenn man schon weiß, dass es so etwas wie eine globale Config Klasse ist, wer wäre so dämlich ein eigenes, lokales Objekt zu erstellen?
Der einzige klassische Anwendungsfall ist es, globale Variablen zu verstecken und das ist dämlich. Es macht den Code nur komplizierter aber in keinster weise schöner.
Nicht kopierbare Objekte machen durchaus an einigen Stellen Sinn und können tatsächlich schwer zu findende Fehler vermeiden. Aber selbst wenn es nur eine einziges Objekt einer Klasse geben darf, müsste man imemr noch so doof sein und explizit ein neues erstellen, von daher kann man wohl sagen, dass ein Leben ganz ohne Singleton besser ist. Die Gefahr es vollkommen falsch zu benutzen ist viel zu groß und der eigentliche Nutzen sehr sehr gering.

Das Problem ist, dass "blub" ein const char* ist, dein Projekt aber im Moment mit UNICODE kompiliert wird und Windows daher einen const wchar_t* von dir will (also z.B. L"blub").
Am besten arbeitest du da mit TCHAR und packst ein TEXT() um den String.
Aber die für den Anfang vielleicht bessere Variante ist, einfach das Character Set in den Projekteigenschaften und General > Character Set auf Not Set stellen.