spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Das Richtige für seinen Fall wäre es keine Globale Variable zu verwenden...

Zitat von »dot«

Das Richtige für seinen Fall wäre es keine Globale Variable zu verwenden...

Genau das meine ich auch.

Zitat von »n0_0ne«

@BurningWave: Ohne sie vorher einmal global zu initialisieren beschwert sich mein compiler (gcc), wenn ich sie im ctor initialisiere. Außerdem will ich sie ja nicht in jedem c'tor initialisieren, sondern nur 1 mal, und die klasse ist nunmal kein singleton

Und was spricht gegen sowas in der Art, wenn die Variable schon statisch sein muss:

Zitat von »n0_0ne«

Der Link war sehr hilfreich, danke, aber er widerspricht (teilweise) dem was du sagst ^^ In meinem Eröffnungspost hatte ich ja von mehreren .cpp dateien gesprochen.

Zitat: "Für zwei globale Variablen aus unterschiedlichen Übersetzungseinheiten ist die Reihenfolge dagegen nicht vorgeschrieben. Daher sollte man nie eine von ihnen mit dem Wert der anderen initialisieren; das Ergebnis kann von Compiler zu Compiler verschieden sein"

Das war genau das, was ich wissen wollte :)

Naja, es ist festgelegt, denn "so wie der Compiler mag" ist auch eine Festlegung. Die eigentlichen Vokabeln um sowas zu beschreiben sind aber "undefined" und "unspecified", denn dazu wird im Standard genau beschrieben, was das heisst.

Zitat von »n0_0ne«

@FalkT: ich verstehe nicht wirklich, was du meinst, könntest du es nochmal erklären?

Ein Singleton regelt den Zugriff auf ein Objekt und dessen Erzeugung.
Normalerweise wird für die Erzeugung der Default-Constructor verwendet.

Ich beziehe mich immer auf die Ausführungen von Alexandrescu in seinem Buch "Modern C++ Design".
Siehe beispielsweise mal Hier .

Die Umsetzung ist dann wie folgt:



Wenn man mehr Magie bei der Erzeugung möchte, dann entsprechend:



Aber die instance-Function muss nicht zwangsweise an die Klasse gebunden sein und die Zugriffs-Funktion muss nicht zwangsläufig static sein.



Ich persönlich finde aber nichts dümmer als von dieser Singleton-Klasse ableiten zu müssen.
Das verfälscht meistens den Zweck von dem was man wirklich tun möchte.

Zitat von »n0_0ne«

Vielleicht ein paar mehr Infos zu meinem Szenario:
Ich habe eine abstrakte (hat pure virtual methoden) Klasse RenderObject mit einigen Hilfsfunktionen und einige Klassen, wie z.B. Cube, Sphere, die von RenderObject erben. Vorher hatte ich die ganzen Daten, wie ein Cube aussieht z.B. in jedem Cube extra gespeichert (sehr viel redundanz). Jetzt will ich es so machen, dass pro Klasse diese daten immer nur 1 mal verfügbar sind, und sie von den hilfsfunktionen von RenderObject genutzt werden können. Mein Vorgehen bis jetzt:
RenderObject eine virtuelle methode getVar() verpasst;virtual, damit immer die passende methode der Kindklasse aufgerufen wird. Diese wird in den Kindklassen implementiert und liefert dann immer die statische variable der Klasse zurück. Diese wird (wie in meinem anfangspost) ein mal mit einer statischen methode initialisiert.

Warum ist dieses vorgehen denn so schlecht? und wie würdet ihr es machen?

Wie klingt folgender Vorschlag für dich:

Du hast eine Klasse Cube die intern die Daten wie ein Cube aussieht etc. hält. Diese Klasse hat eine Methode CreateInstance() der du z.B. die Abmessungen deines Würfels übergibst und die dir ein entsprechendes RenderObjekt* zurückgibt. Problem gelöst, ganz ohne globale oder statische Variablen oder Singletons...

Wenn man es richtig macht ist an globalen Variablen nichts schlimm.
Das Problem ist nur das "richtig machen". Wenn man es eben nicht richtig macht landet man schneller in unwartbarem Code als man es je für möglich gehalten hätte

Jetzt dürft ihr mich gern dafür steinigen, dass ich nicht auf dem Zug "globale variablen sind immer schlimm" mitfahre...

Globale Variablen sind nicht von Haus aus böse. Genausowenig wie Singletons von Haus aus böse sind. Das Problem ist dass 99.99% aller globalen Variablen nicht da sind weil es sich um Dinge handelt die global sein sollten und dass 99.9999% aller Singletons nicht da sind weil es sich um Klassen handelt von denen es immer nur genau eine Instanz geben darf. 99.99% aller globalen Variablen und 99.9999% aller Singletons sind da weil die Programmierer zu faul waren es richtig zu machen und/oder die zugrundeliegenden Konzepte nicht oder falsch verstanden haben. Der Grund für praktisch alle Singletons und globalen Variablen heute ist: "Weil ich von überall aus drauf Zugriff haben will". Und das ist genau das falsche Argument (man beachte wie das Wort "will" plötzlich zu einem "muss" wird sowie dass der globale Zugriff nur ein Nebeneffekt und nicht der eigentlich Sinn hinter dem Singleton Pattern ist). Mehr dazu hier oder hier. Fazit: Globale Variablen und Singletons sind nicht immer schlimm. Aber sie werden praktisch immer falsch verwendet.

Zitat von »n0_0ne«

@dot: so wie ich dich verstanden habe, hat am ende dann aber doch jedes renderobject die topologischen daten gespeichert?

Nein warum? Natürlich erlaubt dir dieses Design das so zu machen wenn du willst. Dein Cube Objekt das sich ja um das Erzeugen der konkreten Instanz kümmert kann so aber auch genauso eine Referenz auf die entsprechenden Daten an die Instanz weitergeben anstatt die Daten zu kopieren, was ja genau das ist was du wolltest oder!?

Zitat von »n0_0ne«

[...] ich initialisiere sie am anfang jetzt einfach global mit NULL und danach nach BurningWaves vorschlag mit einem if(!staticVar) im constructor auf den richtigen wert... seid ihr damit eher einverstanden?

Nein absolut gar nicht. Deine Daten sind offenbar keine globalen Daten, warum also alles daran setzen sie irgendwie in eine globale Variable zu pressen? Nichts spricht hier für eine globale Variable, weder scope noch lifetime deines Objektes. Btw: Wie kümmerst du dich darum dass dein Objekt wieder gelöscht wird?