Antwoord.

Achtergrond:

Het Singleton-patroon is voorgesteld om de creatie van slechts één exemplaar van een bepaalde klasse te beperken, wat nuttig is voor het implementeren van globale beheerders (zoals loggers, resource-pools, configurators).

Probleem:

De implementatie van Singleton lijkt eenvoudig, maar er ontstaan problemen in C++: thread-safety, correcte destructie, initialisatievolgorde.

Oplossing:

De veiligste en meest moderne manier om Singleton te implementeren, maakt gebruik van een statische lokale variabele binnen een statische functie, wat zorgt voor initialisatie bij de eerste aanroep, thread-safety (vanaf C++11) en correcte destructie.

Code voorbeeld:

class Singleton {
public:
    static Singleton& instance() {
        static Singleton s;
        return s;
    }
    void doSomething() {}
private:
    Singleton() {}
    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;
};

Belangrijke kenmerken:

Garantie voor slechts één exemplaar van de klasse.
Lazy creatie van het object en thread-safety (vanaf C++11).
Controle over de levensduur en destructie van het exemplaar.

Misleidende vragen.

Kan er een tweede exemplaar van Singleton worden gemaakt via serialisatie of klonen?

Ja. Als de methoden voor serialisatie/deserialisatie worden geïmplementeerd of als clone() handmatig wordt geïmplementeerd zonder de kopieconstructor te beperken, kan er een tweede exemplaar ontstaan. Om dit te voorkomen, moeten alle manieren van kopiëren, klonen en herstellen via serialisatie worden verboden.

Zal Singleton correct worden geïmplementeerd in een multi-threaded omgeving in C++98/03 standaard met behulp van een lokale statische variabele?

Nee. Lokale statische variabelen garandeerden vóór C++11 geen thread-safety bij initialisatie. Dit kon leiden tot het creëren van meerdere exemplaren als twee threads tegelijkertijd de functie instance() binnenkwamen. In C++11 en nieuwer is dit probleem opgelost op standaardniveau.

Wanneer wordt het Singleton-exemplaar, dat is gemaakt via een statische lokale variabele, vernietigd?

Het object wordt vernietigd in omgekeerde volgorde van creatie (LIFO) tijdens de beëindiging van het programma (exit). Maar dit kan problemen opleveren als in de destructor naar al vernietigde objecten wordt verwiesen.

Veelvoorkomende fouten en anti-patronen

Gebruik van new in plaats van statische variabelen, wat geheugenlekken veroorzaakt.
Kopiëren/toewijzing niet verboden.
Geen rekening gehouden met threads (in oudere standaarden).
Gebruik van shared_ptr of weak_ptr voor het opslaan van het Singleton-exemplaar (schendt uniciteit).

Voorbeeld uit het leven

Negatief geval

In een loggingsysteem implementeert de ontwikkelaar Singleton met behulp van een globale pointer en new, zonder het kopiëren te verbieden. Het programma werkt, maar in een multi-threaded omgeving ontstaan soms verschillende exemplaren van de logger en gaan berichten verloren.

Voordelen:

Eenvoudige implementatie; werkt snel in single-threaded modus.

Nadelen:

Potentiële geheugenlekken.
Schending van uniciteit van het exemplaar in threads.
Problemen met vernietiging.

Positief geval

De Singleton is geïmplementeerd via een statische lokale variabele in een statische functie, waarbij kopiëren is verboden. Thread-safety is gewaarborgd, het programma schaalt goed en logs worden correct gescheiden.