SingleTon Klasse
-
DEvent schrieb:
net schrieb:
DEvent schrieb:
... static void createSingelton(/*Paramter die zum erstellen gut sind*/) { singelton = new Singelton(/*Paramter die zum erstellen gut sind*/); } ...
musst aber noch verhindern, dass 'createSingleton' mehrfach aufgerufen wird. sonst hat man doch mehrere instanzen
wieso das? ein programmierer sollte schon wissen was er macht ...
die regel ist doch ganz einfach: rufe in deiner main funktion einmal createSingelton() auf und am ende dann deleteSingelton. viele APIs haben auch solche einfache regel, wenn man sich nicht drann hält selbst schuld. ( z.b. winapi mit getDC() releaseDC(), oder D3DX mit BeginScene() EndScene() )
aber man könnte ja auch machenvoid createSingelton() { if ( sengelton ) return; singelton = new Singelton(); }
natürlich kann man an der implementierung von singelton rumtricksen aber das prinzip bleibt das gleiche
Du kannst das gerne so machen, aber warum das einfache Prinzip des Singleton
so verkomplizieren? Warum es dem Programmierer nicht einfach machen, deine
Klassen zu benutzen?statische variablen+statische funktionen ≡ Singleton
Das ist natuerlich quatsch. Singletons koennen ohne weiteres nonstatic Member
haben.mfg
v R
-
ps: nur weil mich das mal aus compiler verstehtechnischen gründen in dem
zusammenhang interessiert: verbraucht eine instanz einer klasse ohne nicht
statischen variablen platz im speicher?Ich habe im Draft mal nachgeschaut, aber diesbezueglich nichts gefunden, was ja
eigentlich nicht verwunderlich war, da diese Details besser dem Compilerbauer
ueberlassen werden.mfg
v R
-
DEvent schrieb:
net schrieb:
musst aber noch verhindern, dass 'createSingleton' mehrfach aufgerufen wird. sonst hat man doch mehrere instanzen
wieso das? ein programmierer sollte schon wissen was er macht ...
naja. ich finde es aber schon besser, wenn sich die klassen gegen fehlbedienung selber schützen.
DEvent schrieb:
aber man könnte ja auch machen
void createSingelton() { if ( sengelton ) return; singelton = new Singelton(); }
das ist schon besser. jetzt packst du das noch in deine 'getInstance'-methode und dann ist es sogar benutzerfreundlich.
-
virtuell Realisticer schrieb:
oop schrieb:
@virtuell Realisticer:
dann brauch ich in der klasse kein~Client();
hab ich das richtig verstanden?
cu
Ja, das ist korrekt. In deiner Klasse gibt es nichts, was du per Hand wieder
loeschen musst. Haettest du z. B. sowas: (stark gekuerzt)MyClass() { foo = new bar[100]; }
dann saehe das wieder anders aus, da du dich dann darum kuemmern muesstet,
den Speicherbereich den foo belegt wieder freizugeben. Hier muesstest du dann
einen DTor definieren.In deinem Beispiel oben ist das nicht noetig.
mfg
v Rclass Client { private: // Standard- und Copykonstruktor sind private. // Nur Methoden dieser Klasse können auf sie zugreifen. Client() {} Client( const Client& ); // Dekonstruktor //~Client(); // Ein Zeiger auf die einzige Instanz static Client *m_instanz; public: // Diese statische Methode erzeugt die einzige Instanz. // Nur über diese Methode erhalten Anwender den Zugriff auf // die Instanz. static Client* getInstance(); static void deleteClient() { delete m_instanz; }; }; Client* Client::m_instanz = 0; Client* Client::getInstance() { // Die Instanz wird erst beim ersten Aufruf erzeugt. if( m_instanz == 0 ) m_instanz = new Client(); return m_instanz; } static void Client::deleteClient();
warum soll da der dekonstruktor raus? hast dich glaubi verschaut... ich lösch da mit der delete methode...das objekt...könnte das nicht alles der dekonstruktur machen?
zb:~Client() { delete m_instanz; };
verstehst mich? die frage is halt nur...was ist wenn kein objekt erstellt wurde...dann gibs nen crash mit dem dekontruktor oder?
cu
-
9/3
complete objects and member subobjects of class type shall have nonzero size.
außerdem muss jedes objekt eine eigene adresse haben (was heißt mindestens 1 byte (char) platz).
kannst ja einmal durch ein array durchlaufenstruct Empty { void print () { cout << "address: " << (void*)this << endl; } }; int main () { Empty e[10]; for_each (e, e+sizeof(e)/sizeof(*e), mem_fun_ref(&Empty::print)); }
-
die frage is halt nur...was ist wenn kein objekt erstellt wurde...dann gibs nen
crash mit dem dekontruktor oder?Du hast aber gar keinen Zugriff auf das Objekt. Du bist auf die statische
delete-Memberfunktion gebunden. Fuer m_instanz zu loeschen nutzt dir der DTor
gar nichts, da er nie aufgerufen wird. Er wird erst in dem Moment aufgerufen,
wenn du 'delete m_instanz;' ausfuehrst.@davie
Super und ich suche, suche und suche...es naechste mal frage ich dich gleichmfg
v R
-
Hi!
delete kann auch aufgerufen werden, wenn das Objekt auf 0 zeigt, da passiert gar nichts. Wenn kein Objekt erstellt werden konnte, bzw. zu wenig Speicher vorhanden ist um eine Instanz anzulegen, dann wirft new eine Exeption.
Du brauchst deleteClient nicht nochmal hinschreiben wenn es bereits definiert ist:
static void Client::deleteClient();
Kannst also die letzte Zeile streichen oder dort die definition hinpacken.
Code-Hacker
-
virtuell Realisticer schrieb:
die frage is halt nur...was ist wenn kein objekt erstellt wurde...dann gibs nen
crash mit dem dekontruktor oder?Du hast aber gar keinen Zugriff auf das Objekt. Du bist auf die statische
delete-Memberfunktion gebunden. Fuer m_instanz zu loeschen nutzt dir der DTor
gar nichts, da er nie aufgerufen wird. Er wird erst in dem Moment aufgerufen,
wenn du 'delete m_instanz;' ausfuehrst.@davie
Super und ich suche, suche und suche...es naechste mal frage ich dich gleichmfg
v Rok, dann gibs bei mir kein dekonstruktor wie oben im code! und ich muss eifnach nur selber die delete methode aufrufen!!! ok ok.... hab ich das wohl richtig verstanden? dann is gut...
cu
-
virtuell Realisticer schrieb:
Das ist natuerlich quatsch. Singletons koennen ohne weiteres nonstatic Member
haben.ich glaub wir missverstehen uns. die referenz auf das Singelton-Object sollte static sein, weil es sollte nur eins da sein. natürlich kann die Singelton-Klasse auch nonstatic attribute haben.
-
DEvent schrieb:
virtuell Realisticer schrieb:
Das ist natuerlich quatsch. Singletons koennen ohne weiteres nonstatic Member
haben.ich glaub wir missverstehen uns. die referenz auf das Singelton-Object sollte static sein, weil es sollte nur eins da sein. natürlich kann die Singelton-Klasse auch nonstatic attribute haben.
Ja, da hast du natuerlich vollkommen recht. Sry, da hab ich dich dann in der Tat
falsch verstanden.mfg
v R
-
jedenfalls sind 8 seiten voller missverständnisse schon beachtlich.
dabei hättet ihr es so einfach haben können: http://www.google.com/search?hl=en&ie=UTF-8&q=singleton+design+pattern
-
net schrieb:
jedenfalls sind 8 seiten voller missverständnisse schon beachtlich.
dabei hättet ihr es so einfach haben können: http://www.google.com/search?hl=en&ie=UTF-8&q=singleton+design+patternHaette...und doch ist es sinnvoll, eine solche Diskussion zu fuehren. Und alle
(hoffe ich zumindest) die diesen Thread lesen, merken dass es manchmal sehr
sinnvoll sein kann, wenn man sich etwas deutlicher ausdrueckt.Und wenn du dir den Thread noch einmal durchliest, wirst du feststellen, dass
er nicht voller Missverstaendnisse ist.mfg
v R