Hallo
ich habe eine allgemeine C++ Frage zu instanzen.
Ich habe eine CKlasse1 mit der Funktion(blabla closedevice()) diese Funktion beendet die Irrlicht sitzung.
Sobald diese Instantz von CKlasse1 läuft will ich aus CKlasse2 die Funktion(blabla closedevice()) von CKlasse1
Aufrufen, die muss sich aber auf die Aktuelle instantz beziehen da sonst closedevice() eine Fehler verursacht.

Noch mal ganz kurz " Wie kann ich aus CKlasse2 eine Funktion von CKlasse1 Aufrufen die sich auf die Aktuelle
Instanz von CKlasse1 bezieht."

Gruß MacGyver

_________________
Mein Blog
Ich würde gern die welt ändern, aber Gott gibt mir den Quellcode nicht

Da gibt es zwei Methoden. Die eine ist, dass du einfach Pointer an die Klassen versendest, die auf Klasse 1 zugreifen müssen.

Die andere, die ich in vielen Fällen persönlich schöner finde, sind Singletons.
Angenommen, du benötigst nur eine Instanz von Klasse 1 (das ist bei "closedevice" anzunehmen) gleichzeitig, dann kannst du die Klasse so deklarieren:

Dadurch kann zu jeder Zeit nur eine Instanz der Klasse existieren, der Pointer darauf kann jederzeit über get() abgefragt werden.
Nachteil der Sache ist, dass Konstruktoren/Destruktoren nicht wirklich funktionieren, da die Klasse solange existiert, wie das Programm läuft, bzw bei Programmstart initialisiert wird, du benötigst also zum (de)initialisieren zwei Funktionen.

_________________
Meine Gameengine

also variante 1 (man hält eine referenz bzw einen zeiger auf klasse 1 in klasse 2) ist definitiv die "richtigere", saubere und eindeutig das, was man nutzen sollte wenn man OOP nutzt.

du inkludierst also in klasse 2 einfach klasse 1. irgendwer muss klasse 1 ja erzeugen. im optimalfall sollte das eh klasse 1 sein (wer den dreck macht, sollte ihn auch wegräumen). wer auch immer klasse 1 erzeugt, übergibt dann klasse 2 einen pointer auf klasse 1. und schon kann klasse 2 jede public funktion von klasse 1 nutzen.


singletons sollte man, wie der name schon sagt, nur dann einsetzen, wenn eindeutig feststeht, dass es nur eine instanz einer klasse geben kann und (was sogar viel wichtiger ist) geben DARF. dann, und nur dann sollte man singletons einsetzen.
alles andere ist nur der missbrauch eines singletons für eigentlich globale funktionen.

als ich singletons vor ein paar jahren kennen gelernt habe, war ich auch erst ganz begeistert von denen. inzwischen nutze ich sie eigentlich gar nicht mehr. in 95% der fälle, in denen man vorhat einen singleton zu nutzen, sollte man überlegen, ob nicht irgendwas am code-design suboptimal ist. meistens ist es das dann nämlich. wenn man eh alles in singletons verpackt, kann man gleich rein globale funktionen nehmen.

Singletons sind imho deutlich einfacher und übersichtlicher. Und nur darauf kommt es an

_________________
Meine Gameengine

mit einem singleton aus reiner "einfachheit" (ab einer bestimmten projektgrösse stimmt das auch nicht mehr) hebelst du aber jegliches software-design aus, da JEDE klasse auf die instanz zugreifen kann, auch wenn sie es eigentlich nicht sollte. und zu schnell verfällt man dann in die gewohntheit schnell den singleton zu nehmen und fertig.
das ist aber wie gesagt schlechtes software design, da man quasi nur globale funktionen in module verpackt und das wars.

Singletons sind nützlich und haben ihre daseinsberechtigung. Genau wie jedes andere Design-Pattern.
Es gibt halt Situationen, in denen ein Singleton eben doch die beste/effizienteste Lösung ist.
Was soll ich mit 15 Instanzen meiner Logging klasse? Wofür 2 Datenbankverbindungen, wenn ich nur eine brauche? Warum 13 FileSystem Instanzen?
Design-Patterns sind halt kein must-have. Wenn sie benutzt werden ok. Aber es geht natürlich auch ohne

_________________
Phenom X4 9950 BE | 6144MB DDR2-800 | GeForce 8800GT 512MB | Asus M3A32-MVP Deluxe | 2TB HDD | 520W Seasonic NT | Soprano Tower | Samsung 22" TFT + Fujitsu-Siemens 17" TFT + Toshiba 42" FullHD LCD | Windows 7 Proessional x64
Behind the Brain

ich sagte ja:
"singletons sollte man, wie der name schon sagt, nur dann einsetzen, wenn eindeutig feststeht, dass es nur eine instanz einer klasse geben kann und (was sogar viel wichtiger ist) geben DARF."

bei einem logger würde ich eher nicht zu einem singleton tendieren (obwohl man da sicher, je nach implementierung, diskutieren kann). bei einer datenbankverbindung definitiv nicht. optimalerweise ist diese klasse nämlich so geschrieben, dann sie für verschiedenen datenbanken verwendet werden kann.
filesystem, hat man wahrscheinlich als singleton, diese klasse würde dann aber wohl verschiedene objekte erzeugen (file-objekte etc).

filesystem wär bei den beispielen das einzige wo ich zustimmen würde.
bei anderen gibt es keinen wirklichen grund, das ganze als singleton zu implementieren.
logger kann es durchaus mehrere geben (kann ich gern anhand eines beispiels erläutern, wenn gewünscht). datenbankverbindungen wie gesagt auch. man sollte da nicht so sehr überlegen, was man gerade jetzt im moment braucht, sondern eben ein wenig weiter denken. ein ziel von OOP ist es ja, wiederverwendbaren code zu schreiben. und da zwängt die verwendung von singletons für alles und jedes doch eher ein.

wie gesagt, da wird ein singleton viel zu oft als globale variable missbraucht.