SingleTon Klasse



  • class Client
    {
    private: // Variablen
    	static Client m_Instance;
    };
    

    Erstellen der Instanz:

    Client Client::m_Instance;
    

    Eine Singelton Klasse kann ja nur eine einzige Instanz haben, muss diese statisch sein? is das so richtig wie ich die Instanz anlege?

    bye



  • Hallo,

    beim Singleton ist es so, dass die CTore private sind und eine statische Member-
    funktion bereitgestellt wird, um eine Reference auf eine statische Instanz der
    Klasse zu bekommen:

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

    Damit wird gewaehrleistet, dass es nur eine Instanz der Klasse geben kann.

    mfg
    v R



  • warum hast du keinen dekonstruktor?

    Objektinstanz dynamisch auf dem Heap anlegen:

    class Client
    {
       public:
         static Client* exemplar();
    
       protected:
         Client() {}
    
       private:
         static Client *m_instanz;
         Client( const Client& );
    
    };
    
    Client* Singleton::m_instanz = 0;
    
    Client* Singleton::exemplar()
    {
      if( instanz == 0 )
        m_instanz = new Client();
      return m_instanz;
    }
    

    Wenn das Objekt sehr groß ist oder Ressourcen gebraucht werden, dann legt man die Objektinstanz dynamisch an??
    Dabei stellt sich aber die Frage nach dem Löschen des Objektes????...geht das einfach wenn ich da einen Kopierkonstruktor verwende? bye



  • Hallo,

    in diesem Fall musst du den DTor definieren und das Objekt manuell zerstoeren.

    Ich habe ein Singleton bisher noch nicht auf diese Art und Weise definiert. Ich
    meine mich erinnern zu koennen, dass Hume mal einen Link zu einem Artikel
    gepostet hatte, in dem beschrieben ist wie man das machen kann und das es gar
    nicht so trivial sein soll.

    Ich hoffe ich irre mich hier nicht.

    [edit]
    Ich hatte den Text noch auf der Platte und gleich mal in google gesucht, hier
    der Link:
    http://researchweb.watson.ibm.com/designpatterns/pubs/ph-jun96.txt
    [/edit]

    mfg
    v R



  • 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



  • 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).



  • 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



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



  • 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 🙂



  • Ein Ctor, der einen Wert zurückgibt? 😕



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



  • 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 👎

    🤡



  • 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



  • 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



  • 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



  • Der ist jetzt aber gemein :p

    MfG SideWinder



  • 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;
    }
    


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


Log in to reply