SingleTon Klasse

DEvent

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 machen

void createSingelton()
{
    if ( sengelton ) return;
    singelton = new Singelton();
}

natürlich kann man an der implementierung von singelton rumtricksen aber das prinzip bleibt das gleiche

@virtuell Realisticer:
dann brauch ich in der klasse kein

~Client();

hab ich das richtig verstanden?

cu

DEvent

otze schrieb:

DEvent schrieb:
sovie text für das singelton muster
dabei ist es das einfachste muster überhaupt
ich mach immer:
class Singelton
{
    private:
        static Singelton* singelton;
        Singelton(/*Paramter die zum erstellen gut sind*/);
        ~Singelton();
    public:
        static Singelton* getSingelon() { return singelton; };
        static void createSingelton(/*Paramter die zum erstellen gut sind*/)
        { singelton = new Singelton(/*Paramter die zum erstellen gut sind*/);
        }
        static void deleteSongelton() { delete singelton; };
};
mehr braucht man doch net
...
der weitere punkt ist der: statische variablen+statische funktionen!=Singleton
...

statische variablen+statische funktionen ≡ Singleton

otze

nein, macht aber auch nichts den drin zu haben

virtuell Realisticer

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 R

virtuell Realisticer

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 machen
void 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

virtuell Realisticer

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

net 0

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 R

class 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

davie

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 durchlaufen

struct 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));
}

virtuell Realisticer

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 gleich

mfg
v R

Vellas

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 gleich

mfg
v R

ok, 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

DEvent

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.

virtuell Realisticer

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

net 0

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

virtuell Realisticer

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+pattern

Haette...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