Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

rewb0rn

Supermoderator

  • »rewb0rn« ist der Autor dieses Themas

Beiträge: 2 773

Wohnort: Berlin

Beruf: Indie Game Dev

  • Private Nachricht senden

21

25.08.2005, 15:14

Zitat von »"Dave"«


also geht soetwas in c++?

C-/C++-Quelltext

1
2
3
4
5
6
static class StatischeKlasse
{

}

StatischeKlasse::MeineFunktion();



jooo aber so:

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
 class CKlasse
{
private:
    static int Variable;
public: 
    static void Rechnen();
    static void Ausgeben();
};

//In der cpp Datei den Startwert setzen:

CKlasse::Variable = 0;


usw also alles als static deklarieren. der aufruf dann so wie du gesagt hast

Dave

Alter Hase

Beiträge: 757

Wohnort: Berlin

  • Private Nachricht senden

22

25.08.2005, 15:21

also gibt es doch keine ("echten") statischen klassen in c++ ;)

Anonymous

unregistriert

23

25.08.2005, 16:33

Irgendwie bin ich jetzt verwirrt, bei deinem gezeigten Ansatz hattest du doch irgendein Problem, mit dem Zugriff auf den Manager von überall im Programm, richtig? Und wie genau hast du das jetzt gelöst? Blicke nicht mehr so ganz durch :help:

rewb0rn

Supermoderator

  • »rewb0rn« ist der Autor dieses Themas

Beiträge: 2 773

Wohnort: Berlin

Beruf: Indie Game Dev

  • Private Nachricht senden

24

25.08.2005, 17:19

das habe ich gelöst, indem ich eben weder eine statische klasse noch singletons verwende, sondern anstelle des singletons meinen manager und davon dann die beiden anderen klassen ableite.. jetzt kann ich zB einfach machen:

C-/C++-Quelltext

1
CEffectManager::SetEntry(new tbEffect, "c:\pfad", "besonders toll", "sinnlos");


aber im gegensatz zu statischen klassen funktioniert es wie beim singleton, dass der speicher nicht bei programmstart zugewiesen wird.

Stefan

Alter Hase

Beiträge: 668

Wohnort: Innsbruck

  • Private Nachricht senden

25

02.08.2006, 14:30

Hallo,

ich weiß der Beitrag ist schon etwas älter, aber ich hätte dazu noch eine Frage :)

Ich hab meinen Code komplett auf Singeltones umgestellt und ich hab in Heikos Buch gelesen, dass er nicht jedes mal LogFile::Get() usw. schreibt.
Er verwendet dafür defines, #define g_pLogfile Logfile::Get().

Ist das zu empfehlen, oder lieber doch die lange Version schreiben?


cya,
Stefan

Sheddex

unregistriert

26

02.08.2006, 14:58

Man kann auch einfach an den Anfang der Funktion in der der Singleton verwendet wird CLogfile &Logfile = CLogfile::Get (); schreiben, und dann in der ganzen Funktion wie eine Normale Klasseninstanz verwenden.

Nochmal deutlicher^^

C-/C++-Quelltext

1
2
3
CLogfile &Logfile = CLogfile::Get (); 
Logfile.CreateLogfile ();
Logfile.WriteTopic ();


Ich bevorzuge das so, also wenn ich die Instanz öfters als einmal in einer Funktion brauche...

Stefan

Alter Hase

Beiträge: 668

Wohnort: Innsbruck

  • Private Nachricht senden

27

02.08.2006, 15:11

ah ok danke!
sieht gut aus :)

Stefan

Alter Hase

Beiträge: 668

Wohnort: Innsbruck

  • Private Nachricht senden

28

02.08.2006, 17:17

Singletones unschön?!?!

hm, jetzt habe ich doch noch eine Frage =)

Ich habe gerade mich gerade mit einem Kollegen über meinen Code unterhalten und er meint das Singletones etwas unschönes im Code sind, vorallem wenn man sie öfter benützt. Ich habe zB. als Singletones die 2D Grafikklasse, Texturmanager Klasse, Hauptklasse, Input, Logfile.

Er empfehlt mir lieber eine GameStateManager Klasse, wo ich alle Instanzen erzeuge und dann einfach über diese Klasse drauf zugreife.
GameStateManager->timer->GetTime();
usw.


Was ist denn jetzt schöner bzw. was davon ist mehr OOP... ich kenn mich nicht mehr aus =)


cya,
Stefan

rklaffehn

Treue Seele

Beiträge: 267

Wohnort: Braunschweig

  • Private Nachricht senden

29

02.08.2006, 18:04

Singletons sind unschön!

Singletons sind meistens nicht nötig und werden oft benutzt, um um die OOP herumzukommen, ohne dass man das gleich sieht. Wenn man viele Singletons benutzt, ist das meistens schon ein Fehler. Der Weg über einen GameStateManager ist da auch nicht besser, weil das letzlich auch nur ein Singleton ist.

Nehmen wir doch mal die Logfile Klasse als Beispiel. Wenn die ein Singleton ist, habe ich in den Objekten, die dort etwas reinschreiben wollen keine Wahl, als die eine global vorhandene Log-Datei (oder was auch immer) zu benutzen. Wenn ich nun eine eigenen Log-Datei für Zugriffszeiten und eine für Fehler haben will, müsste ich meinen Singleton durch neue Methoden aufblähen und überall, wo ich das unterscheiden will, muss ich entsprechend die richtigen Methoden des Singleton benutzen. Wenn man da was ändern will, ist das bei großen Projekten schon ein riesen Aufwand.

Wenn ich nun aber nur ein (oder mehrere) Logfile Objekte beim Aufruf von Methoden, oder bei der Erzeugung von Objekten übergebe, habe ich prinzipiell zur Laufzeit die Wahl, welche Logfiles benutzt werden. Ich könnte z.B. wenn mich bestimmte Meldungen nicht interessieren, ein "NULL" Logfile übergeben, das einfach nichts loggt. Man müsste (bis auf das "NULL" Logfile) nirgends etwas an der Implementation ändern, und wenn ich die Meldungen später doch haben will, muss ich nur ein anderes Logfile Objekt übergeben, und schon tauchen sie wieder auf.

Die Essenz hieraus ist, dass ich es mit Objekten (nicht Singletons!) einfacher habe, das Verhalten meiner Applikation zu ändern ohne dass ich gleich überall etwas neu implementieren muss.

Wenn ich das also mal sehr sehr vereinfacht sagen will: OOP ist, wenn man auf Singletons verzichtet.

Es gibt natürlich auch Anwendungen, wo ein Singleton hilft, wie z.B. ein Texturmanager, der verhindert, dass die selbe Textur mehrfach geladen wird. Aber auch hier kann man den Singleton hinter Objekten verstecken; zu einem Mesh gehört dann eben ein TexturSet Objekt, das hinter verschlossener Tür mit dem TexturManager interagiert.

MfG,
Rainer
God is real... unless declared integer.
http://www.boincstats.com/signature/user_967277_banner.gif

Stefan

Alter Hase

Beiträge: 668

Wohnort: Innsbruck

  • Private Nachricht senden

30

03.08.2006, 10:15

Danke, für die gute Erklärung!

Also ich habe jetzt alles schon auf Singletones umgestellt, ich glaub so Sachen wie mehere Log Files usw. werde ich nicht benötigen und werde es deshalb erst mal so lassen.
Aber für die nächsten Projekte werde ich sie wohl besser weg lassen.

Werbeanzeige