SingleTon Klasse

KPC

Dein Muster ist einfach, weil es nicht komplett ausgereift ist:

Man muss selber die create/delete Methoden des Singletons aufrufen! Das kann man sehr leicht vergessen, vor allem die delete Methode, denn wenn man die vergisst passiert nichts schlimmes, man hat "nur" ein Memoryleak. Klar beim create kracht es sofort, trotzdem ist das nicht besonders schön.

Sollte außerdem irgendwo eine Exception geschmissen werden, die nicht gefangen wird, dann wird dein Singleton auch nicht zerstört (es kann ja keiner die delete Methode aufrufen).

groovemaster

oop schrieb:

Wenn das Objekt sehr groß ist oder Ressourcen gebraucht werden, dann legt man die Objektinstanz dynamisch an??

Nicht unbedingt, du kannst auch dann mit static arbeiten.

ich bin am designen meiner Client bzw Server Klasse!
hab da so methoden wie:

void SendToAllClients(std::string);

drinnen...

was ist da zu bevorzugen, Objektinstanz dynamisch oder statisch anlegen?
hab wenig erfahrung damit!

cu

Hallo,

oop schrieb:

ich bin am designen meiner Client bzw Server Klasse!
hab da so methoden wie:
void SendToAllClients(std::string);
drinnen...

was ist da zu bevorzugen, Objektinstanz dynamisch oder statisch anlegen?
hab wenig erfahrung damit!

cu

du koenntest die entsprechenden Instanzen in einem Vector speichern und
innerhalb von SendToAllClients machst du dann sowas wie

client_vec[i].send(my_string);

Das selbe dann natuerlich auch fuer die Serverinstanzen.

mfg
v R

7H3 N4C3R

Das "sicherste" und einfachste Singleton ist immernoch das Myersche Singleton. Hatten wir ja oben schon:

class Client {
    private:
        Client();
    public:
        static Client& getInstance() {
            static Client client;
            return client;
        }
};

Einziges Problem dabei ist, dass wenn man mehrere davon hat, die Destruktorreihenfolge nicht festgelegt ist. Vor allem dann ist es schwierig, wenn die Singletons beim Zerstören aufeinander Bezug nehmen müssen. Dass eine Instanz schon zerstört ist, bemerkt man nämlich nur an sehr schwer nachvollziehbaren Fehlermeldungen.

otze

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

das muster find ich nicht so toll,wenn das singleton zerstört wird, und auf das innere singleton objekt noch ein verweis besteht, wird die ganze sache übel,ohne ein phönix singleton käme man da nicht aus...

der weitere punkt ist der: statische variablen+statische funktionen!=Singleton

ohja, und noch ein kritikpunkt:

int main(){
Singleton::deleteSingelton();//und nun?
Singleton::createSingelton(5);
Singleton* a=getSingelton();
Singleton::createSingelton(6);//und nun?
}

ich benutze im moment so ein singleton:

template<class T>
class Singleton{
    private:
        static T* objectPointer;
        static int ref;
    public:
        Singleton(){
            if(!objectPointer){
                objectPointer=new T;
            }
            ++ref; 
        };
        ~Singleton(){
            if(!--ref){
                delete objectPointer;
            }
        }
        T* operator ->(){
            return objectPointer;
        }
};

habs jetzt mal aus dem kopf geschrieben, aber es funktioniert ganz gut

interpreter

Ein Ctor, der einen Wert zurückgibt?

otze

arrgh, dabei ist es doch noch garnicht so spät
man nich soviels aufen otze, dann wirds auch mal was mit dem programmieren

interpreter

otze schrieb:

arrgh, dabei ist es doch noch garnicht so spät
man nich soviels aufen otze, dann wirds auch mal was mit dem programmieren

SideWinder

Mit den Templates kann ich mich nicht sonderlich anfreunden, was hier:

class einmalbitte
{
    // Toller Konstruktor der nur einmal passieren darf
};

// und so erstellen? nicht sehr intuitiv:
Singleton<einmalbitte> A;

// okay typedef
typedef Singleton<einmalbitte> realeinmalbitte;

realeinmalbitte A;
einmalbitte B;
einmalbitte is_eh_schon_gecrashed;

Oder gibts dafür einen Trick? Also ich bin immer noch dafür, dass man sich die Mühe macht für jede Klasse das Singleton selbst zu bauen :). Dann könnte man die Singleton-Klasse zum friend machen und den Konstruktor erst wieder private. Da kann ich mir mein Singleton aber selbst schreiben auch ;).

/me ist für die Einführung der Keywörter abstract und single

MfG SideWinder

otze

realeinmalbitte A;
einmalbitte B;

ja es gibt nen trick:
du machst wie gesagt den ctor von einmalbitte private und singleton zum friend davon^^

man könnte es aber auch so machen:

class einmalbitte_
{
    // Toller Konstruktor der nur einmal passieren darf
};

typedef Singleton<einmalbitte_> einmalbitte

einmalbitte A;
einmalbitte B;
einmalbitte is_eh_noch_nicht_gecrashed;

/me ist für die Einführung der Keywörter abstract und single

net 0

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

SideWinder

Der ist jetzt aber gemein :p

MfG SideWinder

interpreter

Ich finde otzes Version nicht gut, da sie dem Prinzip des Singleton-Pattern widerspricht. Das Singleton-Pattern soll sicherstellen, dass es von einer Klasse maximal eine Instanz geben kann. Bei deiner Lösung kann ich jedoch unendlich viele Instanzen anlegen (sie teilen sich ja nur den Inhalt).
IMHO ist diese eine gute Implementierung:

#include <iostream>
using namespace std;

class Singleton {
private:
    static bool instanceFlag;
    static Singleton *single;
    Singleton() {
        //private constructor
    }
public:
    static Singleton* getInstance();
    void method();
    ~Singleton() {
        instanceFlag = false;
    }
};

bool Singleton::instanceFlag = false;
Singleton* Singleton::single = NULL;
Singleton* Singleton::getInstance() {
    if(! instanceFlag) {
        single = new Singleton();
        instanceFlag = true;
        return single;
    }
    else
        return single;

}

void Singleton::method() {
    cout << "Method of the singleton class" << endl;
}

otze

Ich finde otzes Version nicht gut, da sie dem Prinzip des Singleton-Pattern widerspricht. Das Singleton-Pattern soll sicherstellen, dass es von einer Klasse maximal eine Instanz geben kann. Bei deiner Lösung kann ich jedoch unendlich viele Instanzen anlegen (sie teilen sich ja nur den Inhalt).

versteh ich nicht.

SideWinder

@otze: Siehe mein Beispiel, ich glaube das meint er.

@interpreter: new ohne delete? o-O :p

MfG SideWinder

interpreter

Singleton Pattern besagt: Es darf maximal eine Instanz der Klasse geben.

Bei deiner Version kann ich locker das machen:
Singleton<int> s1, s2, s3, s4;
und schon habe ich 4 Instanzen.

interpreter

SideWinder schrieb:

@interpreter: new ohne delete? o-O :p

Das delete muss halt der Benutzer aufrufen, wenn er das Objekt nicht mehr benötigt (oder u.U. ne statische destroyInstance() Methode anbieten)

otze

@sidewinder am template kanns nicht liegen, das macht der gute andrei alexandrescou genauso

Singleton Pattern besagt: Es darf maximal eine Instanz der Klasse geben.

ok, diese regel brech ich, aber nur insofern, dass der rumpf der klasse mehrfach existiert, im gegenzug verhindere ich aber, dass referenzen oder pointer auf das innenleben des objekts erstellt werden,sodass ich mir garkeine sorgen um ein externes delete zu machen brauche

Shlo

interpreter schrieb:

Singleton Pattern besagt: Es darf maximal eine Instanz der Klasse geben.

Lesen und vor allem Suchen bildet: http://www.c-plusplus.net/forum/viewtopic.php?t=57731&highlight=singleton