Modello di progettazione Singleton C ++

Di recente mi sono imbattuto in una realizzazione / implementazione del modello di progettazione Singleton per C ++. È stato così (l'ho adottato dall'esempio della vita reale):

// a lot of methods are omitted here
class Singleton
{
   public:
       static Singleton* getInstance( );
       ~Singleton( );
   private:
       Singleton( );
       static Singleton* instance;
};

Da questa dichiarazione posso dedurre che il campo dell'istanza è iniziato sull'heap. Ciò significa che c'è un'allocazione di memoria. Ciò che non è completamente chiaro per me è quando esattamente la memoria verrà deallocata? O c'è un bug e una perdita di memoria? Sembra che ci sia un problema nell'implementazione.

La mia domanda principale è: come posso implementarla nel modo giusto?

Nel 2008 ho fornito un'implementazione in C ++ 98 del modello di progettazione Singleton che è lazy-rated, garanzia di distruzione, non tecnicamente sicura per i thread:
qualcuno può fornirmi un campione di Singleton in c ++?

Ecco un'implementazione C ++ 11 aggiornata del modello di progettazione Singleton valutato in modo pigro, distrutto correttamente e sicuro per i thread .

class S
{
    public:
        static S& getInstance()
        {
            static S    instance; // Guaranteed to be destroyed.
                                  // Instantiated on first use.
            return instance;
        }
    private:
        S() {}                    // Constructor? (the {} brackets) are needed here.

        // C++ 03
        // ========
        // Don't forget to declare these two. You want to make sure they
        // are unacceptable otherwise you may accidentally get copies of
        // your singleton appearing.
        S(S const&);              // Don't Implement
        void operator=(S const&); // Don't implement

        // C++ 11
        // =======
        // We can use the better technique of deleting the methods
        // we don't want.
    public:
        S(S const&)               = delete;
        void operator=(S const&)  = delete;

        // Note: Scott Meyers mentions in his Effective Modern
        //       C++ book, that deleted functions should generally
        //       be public as it results in better error messages
        //       due to the compilers behavior to check accessibility
        //       before deleted status
};

Vedi questo articolo su quando usare un singleton: (non spesso)
Singleton: come dovrebbe essere usato

Consulta questo articolo sull'ordine di inizializzazione e su come gestirlo:
ordine di inizializzazione delle variabili statiche
Individuazione dei problemi relativi all'ordine di inizializzazione statica C ++

Vedi questo articolo che descrive i tempi di vita:
qual è la durata di una variabile statica in una funzione C ++?

Vedi questo articolo che discute alcune implicazioni del threading sui singleton:
istanza Singleton dichiarata come variabile statica del metodo GetInstance, è thread-safe?

Leggi questo articolo che spiega perché il doppio controllo bloccato non funzionerà su C ++:
quali sono tutti i comportamenti comuni non definiti che un programmatore C ++ dovrebbe conoscere?
Dr Dobbs: C ++ e The Perils of Double-Checked Locking: Part I

Essendo un Singleton, di solito non vuoi che venga distrutto.

Verrà abbattuto e deallocato al termine del programma, che è il comportamento normale desiderato per un singleton. Se vuoi essere in grado di ripulirlo esplicitamente, è abbastanza facile aggiungere un metodo statico alla classe che ti consenta di ripristinarlo in uno stato pulito e di riallocarlo la prossima volta che viene utilizzato, ma non rientra nell'ambito di un singleton "classico".

È possibile evitare l'allocazione di memoria. Esistono molte varianti, tutte con problemi in caso di ambiente multithreading.

Preferisco questo tipo di implementazione (in realtà, non si dice correttamente che preferisco, perché evito il più possibile i singoli punti):

class Singleton
{
private:
   Singleton();

public:
   static Singleton& instance()
   {
      static Singleton INSTANCE;
      return INSTANCE;
   }
};

Non ha allocazione dinamica della memoria.

La risposta di @Loki Astari è eccellente.

Tuttavia, ci sono momenti con più oggetti statici in cui è necessario essere in grado di garantire che il singleton non verrà distrutto fino a quando tutti gli oggetti statici che usano il singleton non ne avranno più bisogno.

In questo caso std::shared_ptrpuò essere utilizzato per mantenere in vita il singleton per tutti gli utenti anche quando i distruttori statici vengono chiamati alla fine del programma:

class Singleton
{
public:
    Singleton(Singleton const&) = delete;
    Singleton& operator=(Singleton const&) = delete;

    static std::shared_ptr<Singleton> instance()
    {
        static std::shared_ptr<Singleton> s{new Singleton};
        return s;
    }

private:
    Singleton() {}
};

Un'altra alternativa non allocante: crea un singleton, diciamo di classe C, quando ne hai bisogno:

singleton<C>()

utilizzando

template <class X>
X& singleton()
{
    static X x;
    return x;
}

Né questa né la risposta di Cătălin sono automaticamente thread-safe nell'attuale C ++, ma saranno in C ++ 0x.

Non ho trovato un'implementazione CRTP tra le risposte, quindi eccola:

template<typename HeirT>
class Singleton
{
public:
    Singleton() = delete;

    Singleton(const Singleton &) = delete;

    Singleton &operator=(const Singleton &) = delete;

    static HeirT &instance()
    {
        static HeirT instance;
        return instance;
    }
};

Per usare basta ereditare la tua classe da questo, come: class Test : public Singleton<Test>

La soluzione nella risposta accettata presenta un significativo svantaggio: il distruttore per il singleton viene chiamato dopo che il controllo lascia la main()funzione. Potrebbero esserci davvero dei problemi quando alcuni oggetti dipendenti sono allocati all'internomain .

Ho riscontrato questo problema durante il tentativo di introdurre un Singleton nell'applicazione Qt. Ho deciso che tutte le mie finestre di dialogo di installazione devono essere Singleton e ho adottato il modello sopra. Sfortunatamente, la classe principale di Qt è QApplicationstata allocata nello stack nella mainfunzione e Qt proibisce la creazione / distruzione di finestre di dialogo quando non è disponibile alcun oggetto applicazione.

Questo è il motivo per cui preferisco i singleton allocati in heap. Fornisco un esplicito init()e term()metodi per tutti i singoli e li chiamo all'interno main. Quindi ho il pieno controllo sull'ordine di creazione / distruzione dei singoli, e garantisco anche che verranno creati i singoli, indipendentemente dal fatto che qualcuno abbia chiamato getInstance()o meno.

Ecco una facile implementazione.

#include <Windows.h>
#include <iostream>

using namespace std;


class SingletonClass {

public:
    static SingletonClass* getInstance() {

    return (!m_instanceSingleton) ?
        m_instanceSingleton = new SingletonClass : 
        m_instanceSingleton;
    }

private:
    // private constructor and destructor
    SingletonClass() { cout << "SingletonClass instance created!\n"; }
    ~SingletonClass() {}

    // private copy constructor and assignment operator
    SingletonClass(const SingletonClass&);
    SingletonClass& operator=(const SingletonClass&);

    static SingletonClass *m_instanceSingleton;
};

SingletonClass* SingletonClass::m_instanceSingleton = nullptr;



int main(int argc, const char * argv[]) {

    SingletonClass *singleton;
    singleton = singleton->getInstance();
    cout << singleton << endl;

    // Another object gets the reference of the first object!
    SingletonClass *anotherSingleton;
    anotherSingleton = anotherSingleton->getInstance();
    cout << anotherSingleton << endl;

    Sleep(5000);

    return 0;
}

Viene creato solo un oggetto e questo riferimento all'oggetto viene restituito ogni volta dopo le parole.

SingletonClass instance created!
00915CB8
00915CB8

Qui 00915CB8 è la posizione di memoria dell'oggetto Singleton, uguale per la durata del programma ma (normalmente!) Diverso ogni volta che il programma viene eseguito.

NB Questo non è un filo sicuro. Devi garantire la sicurezza del filo.

Se si desidera allocare l'oggetto nell'heap, perché non utilizzare un puntatore univoco. Anche la memoria verrà deallocata poiché stiamo utilizzando un puntatore univoco.

class S
{
    public:
        static S& getInstance()
        {
            if( m_s.get() == 0 )
            {
              m_s.reset( new S() );
            }
            return *m_s;
        }

    private:
        static std::unique_ptr<S> m_s;

        S();
        S(S const&);            // Don't Implement
        void operator=(S const&); // Don't implement
};

std::unique_ptr<S> S::m_s(0);

È probabilmente probabilmente allocato dall'heap, ma senza le fonti non c'è modo di saperlo.

L'implementazione tipica (presa da un codice che ho già in emacs) sarebbe:

Singleton * Singleton::getInstance() {
    if (!instance) {
        instance = new Singleton();
    };
    return instance;
};

... e fare affidamento sul fatto che il programma esca dal campo di applicazione per ripulire in seguito.

Se lavori su una piattaforma in cui la pulizia deve essere eseguita manualmente, probabilmente aggiungerei una routine di pulizia manuale.

Un altro problema nel farlo in questo modo è che non è thread-safe. In un ambiente multithread, due thread potrebbero superare il "if" prima che uno dei due abbia la possibilità di allocare la nuova istanza (quindi entrambi lo farebbero). Questo non è ancora un grosso problema se si fa affidamento sulla conclusione del programma per ripulire comunque.

Qualcuno ha menzionato std::call_oncee std::once_flag? La maggior parte degli altri approcci, incluso il blocco con doppio controllo, non funziona.

Un grave problema nell'implementazione del modello singleton è l'inizializzazione sicura. L'unico modo sicuro è proteggere la sequenza di inizializzazione con barriere di sincronizzazione. Ma queste stesse barriere devono essere avviate in sicurezza. std::once_flagè il meccanismo per ottenere un'inizializzazione sicura garantita.

Di recente abbiamo approfondito questo argomento nella mia classe EECS. Se vuoi guardare le note della lezione in dettaglio, visita http://umich.edu/~eecs381/lecture/IdiomsDesPattsCreational.pdf

Ci sono due modi che conosco per creare correttamente una classe Singleton.

Primo modo:

Implementalo in modo simile al modo in cui lo hai nel tuo esempio. Per quanto riguarda la distruzione, "I singoli di solito durano per la durata dell'esecuzione del programma; la maggior parte dei sistemi operativi recupererà la memoria e la maggior parte delle altre risorse quando un programma termina, quindi c'è un argomento per non preoccuparsi di questo".

Tuttavia, è buona norma ripulire al termine del programma. Pertanto, è possibile farlo con una classe SingletonDestructor ausiliaria statica e dichiararlo come amico nel proprio Singleton.

class Singleton {
public:
  static Singleton* get_instance();

  // disable copy/move -- this is a Singleton
  Singleton(const Singleton&) = delete;
  Singleton(Singleton&&) = delete;
  Singleton& operator=(const Singleton&) = delete;
  Singleton& operator=(Singleton&&) = delete;

  friend class Singleton_destroyer;

private:
  Singleton();  // no one else can create one
  ~Singleton(); // prevent accidental deletion

  static Singleton* ptr;
};

// auxiliary static object for destroying the memory of Singleton
class Singleton_destroyer {
public:
  ~Singleton_destroyer { delete Singleton::ptr; }
};

Il Singleton_destroyer verrà creato all'avvio del programma e "quando il programma termina, tutti gli oggetti globali / statici vengono distrutti dal codice di arresto della libreria di runtime (inserito dal linker), quindi il_destroyer verrà distrutto; il suo distruttore eliminerà il Singleton, eseguendo il suo distruttore."

Secondo modo

Questo si chiama Meyers Singleton, creato dal mago del C ++ Scott Meyers. Definisci semplicemente get_instance () in modo diverso. Ora puoi anche sbarazzarti della variabile membro puntatore.

// public member function
static Singleton& Singleton::get_instance()
{
  static Singleton s;
  return s;
}

Questo è pulito perché il valore restituito è per riferimento ed è possibile utilizzare la .sintassi invece di ->accedere alle variabili dei membri.

"Il compilatore crea automaticamente il codice che crea la prima volta attraverso la dichiarazione, non successivamente, e quindi elimina l'oggetto statico al termine del programma."

Si noti inoltre che con Meyers Singleton è possibile "trovarsi in una situazione molto difficile se gli oggetti si basano l'uno sull'altro al momento della terminazione - quando Singleton scompare rispetto ad altri oggetti? Ma per applicazioni semplici, funziona bene".

Oltre all'altra discussione qui, può valere la pena notare che si può avere la globalità, senza limitare l'utilizzo a un'istanza. Ad esempio, considera il caso di riferimento contando qualcosa ...

struct Store{
   std::array<Something, 1024> data;
   size_t get(size_t idx){ /* ... */ }
   void incr_ref(size_t idx){ /* ... */}
   void decr_ref(size_t idx){ /* ... */}
};

template<Store* store_p>
struct ItemRef{
   size_t idx;
   auto get(){ return store_p->get(idx); };
   ItemRef() { store_p->incr_ref(idx); };
   ~ItemRef() { store_p->decr_ref(idx); };
};

Store store1_g;
Store store2_g; // we don't restrict the number of global Store instances

Ora da qualche parte all'interno di una funzione (come main) puoi fare:

auto ref1_a = ItemRef<&store1_g>(101);
auto ref2_a = ItemRef<&store2_g>(201); 

Non è necessario che i ref memorizzino un puntatore nei rispettivi Storeperché tali informazioni vengono fornite in fase di compilazione. Inoltre, non devi preoccuparti della Storevita perché il compilatore richiede che sia globale. Se c'è davvero solo un'istanza di Storeallora non ci sono spese generali in questo approccio; con più di un'istanza spetta al compilatore essere intelligente sulla generazione del codice. Se necessario, la ItemRefclasse può anche essere composta friendda Store(puoi avere degli amici templati!).

Se di per Storesé è una classe basata su modelli, le cose diventano più difficili, ma è ancora possibile utilizzare questo metodo, forse implementando una classe di supporto con la seguente firma:

template <typename Store_t, Store_t* store_p>
struct StoreWrapper{ /* stuff to access store_p, e.g. methods returning 
                       instances of ItemRef<Store_t, store_p>. */ };

L'utente può ora creare un StoreWrappertipo (e un'istanza globale) per ogni Storeistanza globale e accedere sempre ai negozi tramite la loro istanza wrapper (dimenticando così i dettagli cruenti dei parametri del modello necessari per l'utilizzo Store).

Si tratta della gestione della durata degli oggetti. Supponiamo di avere più di singoli nel tuo software. E dipendono da Logger singleton. Durante la distruzione dell'applicazione, supponiamo che un altro oggetto singleton utilizzi Logger per registrare i suoi passaggi di distruzione. Devi garantire che Logger debba essere pulito per ultimo. Pertanto, consulta anche questo documento: http://www.cs.wustl.edu/~schmidt/PDF/ObjMan.pdf

La mia implementazione è simile a quella di Galik. La differenza è che la mia implementazione consente ai puntatori condivisi di ripulire la memoria allocata, invece di trattenerla fino a quando l'applicazione non viene chiusa e i puntatori statici vengono ripuliti.

#pragma once

#include <memory>

template<typename T>
class Singleton
{
private:
  static std::weak_ptr<T> _singleton;
public:
  static std::shared_ptr<T> singleton()
  {
    std::shared_ptr<T> singleton = _singleton.lock();
    if (!singleton) 
    {
      singleton.reset(new T());
      _singleton = singleton;
    }

    return singleton;
  }
};

template<typename T>
std::weak_ptr<T> Singleton<T>::_singleton;

Il codice è corretto, tranne per il fatto che non hai dichiarato il puntatore all'istanza al di fuori della classe . Le dichiarazioni di variabili statiche all'interno della classe non sono considerate dichiarazioni in C ++, tuttavia ciò è consentito in altri linguaggi come C # o Java ecc.

class Singleton
{
   public:
       static Singleton* getInstance( );
   private:
       Singleton( );
       static Singleton* instance;
};
Singleton* Singleton::instance; //we need to declare outside because static variables are global

Devi sapere che l'istanza Singleton non deve essere eliminata manualmente da noi . Abbiamo bisogno di un singolo oggetto per tutto il programma, quindi alla fine dell'esecuzione del programma, verrà automaticamente deallocato.

Il documento che è stato collegato sopra descrive il difetto del doppio controllo verificato è che il compilatore può allocare la memoria per l'oggetto e impostare un puntatore all'indirizzo della memoria allocata, prima che il costruttore dell'oggetto sia stato chiamato. È abbastanza facile in c ++ usare gli allocatori per allocare manualmente la memoria e quindi usare una chiamata di costruzione per inizializzare la memoria. Usando questa valutazione, la chiusura a doppio controllo funziona bene.

#define INS(c) private:void operator=(c const&){};public:static c& I(){static c _instance;return _instance;}

Esempio:

   class CCtrl
    {
    private:
        CCtrl(void);
        virtual ~CCtrl(void);

    public:
        INS(CCtrl);

Semplice classe singleton, deve essere il file della classe di intestazione

#ifndef SC_SINGLETON_CLASS_H
#define SC_SINGLETON_CLASS_H

class SingletonClass
{
    public:
        static SingletonClass* Instance()
        {
           static SingletonClass* instance = new SingletonClass();
           return instance;
        }

        void Relocate(int X, int Y, int Z);

    private:
        SingletonClass();
        ~SingletonClass();
};

#define sSingletonClass SingletonClass::Instance()

#endif

Accedi al tuo singleton in questo modo:

sSingletonClass->Relocate(1, 2, 5);

Penso che dovresti scrivere una funzione statica in cui il tuo oggetto statico viene eliminato. Dovresti chiamare questa funzione quando stai per chiudere la tua applicazione. Ciò assicurerà di non avere perdite di memoria.