spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hallo,

Singletons haben einen Vorteil gegenüber statischen Klassen. Nehmen wir einmal an wir haben eine CUniverse-Klasse. Nun schreiben wir irgendein Programm was mit Plug-Ins arbeitet und jedes Plug-In soll Zugriff auf die Methoden unserer CSpecialUniverse-Klasse (von CUniverse abgeleitet) bekommen, welche sich in unserem Programm befindet. Die Deklaration von CUniverse ist den Plug-Ins bekannt.

Mit einer statischen Klasse kommt man an dieser Stelle wahrscheinlich nicht sehr weit. Mit einer Instanz welche wir als Pointer ans Plug-In übergeben können, ermöglichen wir so den Zugriff auf unsere CSpecialUniverse-Klasse.

Natürlich ist damit die Frage "warum Singletons?" nicht beantwortet, sondern nur, warum man eine "Instanz-Implementierung" an dieser Stelle einer statischen Klasse vorziehen sollte.

Gruß
Ketchup

Was ich bei einem Singleton nicht verstehe ist, wie es wieder gelöscht wird. Legt man es mit new an, dann sollte es doch auch mit delete wieder entfernt werden oder sehe ich das falsch?

Nö das siehst du genau richtig. Die meisten benutzen dafür allerdings eine static Variabel. Das sieht dann meistens so aus
Dann wird die Klasse beim ersten aufruf Automatisch erzeugt und beim Beenden des Programms auch wieder automatisch entfernt. Vieleicht schaust du dir mal "static" Variabeln an.
Die dritte möglichkeit währe eine Globale Instanz der Klasse zu erzeugen.

Das mit Static kenne ich schon, nur wird da die Klasse ja schon bei Programmstart angelegt, bei new erst dann wenn sie wirklich gebraucht wird. Ich finde das alles nicht so toll. Dann sorge ich doch lieber selber dafür, dass ich als Programmierer nur eine Instanz anlege.

Hi!

Vielleicht sollte man bei Singletons in Größeren Maßstäben denken. Letztendlich verhalten sich z.B. DLL-Dateien ja auch nicht anders. Wenn mehrere Programme dieselbe DLL-Datei laden/anfordern, wird sie ja auch nur einmal geladen und existiert auch nur einmal im Speicher.
Bei großen Projekten würden Singletons also einfach als Speicherersparnis angewandt werden. Z.B. könnte man einen Speichermanager als Singleton implementieren. Wenn nun irgendein Modul Speicher über ihn anfordert wird er erzeugt. Alle weiteren Speicherfunktionen würden immer über diese eine Speichermanager-Instanz arbeiten. Und da der Speichermanager als Instanz existiert, kann ich ihn auch an andere Module weitergeben (nämlich mit Pointern) (siehe weiter oben).

Die Realisierung mit static-Variablen finde ich garnicht schlecht und unsauber ist es auch nicht.
Nur dieser GetInstance-Aufruf stört mich etwas. Ich habe auch schonmal eine (wohl unsaubere) Lösung mit einem (verkorksten?) Konstruktor gesehen. Aber eigentlich müsste es doch reichen, wenn man den new- und delete-Operator der Klasse überschreiben und anpassen würde, oder nicht?

Gruß
Ketchup

Ich finde das sich Singletons besonders für Manager gut eignen. Z.B. einen Engine Manager. Mein Memory Tracker ist ebenfalls als Singleton Designed. Das erleichtert erheblich die Verwendung.

Was die GetInstance Methode angeht. Ich Kapsel die immer in einer inline Funktion, weil ich einfach kein Bock hab immer Class::GetInstance() zu schreiben. Die Inline Funktionen heißen bei mir dann meißt wie die Klasse. Als z.B. Manager().

Natürlich kann man den new Operator für ein Singleton überladen. Ist nur die Frage ob das nötig ist. Ein Normaler aufruf mit dem Standard new-Operator reicht dann auch aus.

Stimmt, an Manager() habe ich garnicht gedacht, ist auch eine schöne Möglichkeit. :-)

Gruß
Ketchup

Könnte es da nicht Verwechselungsprobleme geben? Wenn ich Manager() schreibe, könnte entweder die Funktion Manager() gemeint sein oder ein eventueller Konstruktor der Manager-Klasse!

Nicht wenn man CManager als Klassennamen verwendet.

Gruß
Ketchup

*g* War ja nur ein Beispiel. Ein Konkretes Beispiel aus meiner Engine. Alle Engine Klassen befinden sich im r3d Namespace und meine Manager Klasse heißt Ravange3DManager. Die entsprechende Funktion heißt bei mir also "r3dManager()" und befindet sich nicht in dem r3d Namespace. Eine verwechslung ist hier ausgeschlossen.

Aber klar, wenn man die Namen ungünstig wählt könnte es zu verwechslungen kommen.