Singletons en C++

Il peut arriver qu'on ait besoin de classes à instanciation unique.

Aussi étrange que ce concept puisse apparaître, il est relativement fréquent qu'on y ait recours (ou qu'on rencontre une situation pour laquelle ce serait une approche viable) dans des projets de la vie courante.C'est même un schéma de conception (un Design Pattern) répandu.

Pourquoi vouloir un singleton?

Bien que les singletons représentent une famille de classes particulière – il ne s'agit pas là de l'approche orientée objet la plus typique ou la plus souvent rencontrée – il existe plusieurs raisons envisageables pour désirer avoir recours à une classe de ce genre.

Pensons par exemple à :

• Un objet conçu pour représenter un composant matériel peut être restreint à une seule instanciation pour éviter des conflits de gestion des ressources
• Une situation où on voudra faire en sorte qu'un même objet (qu'un seul objet) soit affecté à la tâche de répondre aux multiples besoins d'un programme, mais on voudra que cet objet soit utilisable à travers une interface (donc qu'il s'agisse d'une singleton dont la classe est dérivée d'une interface connue), ou encore à
• Un objet qui servira de gestionnaire unique pour d'autres objets, question d'automatiser certains mécanismes d'un programme

Une fois la nécessité occasionnelle de singletons acceptée, reste à savoir comment implanter ce concept. Heureusement, c'est là quelque chose de relativement simple. Nous verrons ici comment procéder, de plusieurs manières différentes. Un risque potentiel de l'emploi de singletons – les accès concurrents – sera mentionné au passage, mais sa solution réelle sera escamotée ici .

Assurer l'instanciation unique : quelques stratégies

Plusieurs stratégies sont possibles pour empêcher une classe d'être instanciée plus d'une fois dans un programme, mais toutes ces stratégies ont en commun un certain nombre d'éléments, parmi lesquels on trouve :

• Le recours à un constructeur privé, typiquement un constructeur par défaut. Ceci empêche le code client d'accéder aux constructeurs et d'instancier lui-même la classe destinée à être un singleton. Utiliser un constructeur privé empêche aussi la mise en place de classes dérivées du singleton, évitant un cas un peu pervers de duplication auquel trop de développeurs ne pensent pas
  • Notez au passage qu'il est improbable (quoique pas impossible) que définir d'autres constructeurs que le constructeur par défaut soit pertinent. Après tout, par définition, un singleton ne sera instancié qu'une fois, et généralement de manière contrôlée
• Des mécanismes pour empêcher la duplication du singleton. Souvenons-nous que C++ offre une implémentation par défaut des mécanismes de copie que son constructeur de copie et l'opérateur d'affectation. Nous voudrons bloquer ce comportement; pour ce faire, nous appliquerons l'idiome de classe incopiable
• Un destructeur public, pour des raisons techniques
  • Il est possible d'omettre cette dernière contrainte à l'occasion (nous y reviendrons)
• Un mécanisme interne à la classe pour définir le singleton. Ce mécanisme reposera souvent, mais pas toujours, sur un attribut de classe, et
• Une stratégie d'encapsulation du singleton, pour contrôler les accès à cet objet et éviter les accidents en situation de multiprogrammation

Approche 0 – membre de classe et instanciation sur demande

Avec cette approche, l'singleton sera allouée dynamiquement et son adresse sera affectée à un attribut de classe, que nous avec nommé ici singleton – parce qu'il s'agit de l'unique singleton qui sera jamais construite de cette classe dans tout programme – et qui est initialisé à zéro, prenant ici le sens de pointeur nul.

L'instanciation est faite lors d'un appel à une méthode (ici get()), ce qui fait que l'objet ne sera créé que si au moins une demande d'accès y est faite. Seul le premier appel à cette méthode résultera en une instanciation; les appels subséquents réutiliseront tous l'instance initialement construite.

Notez que chaque appel à get() nécessite l'évaluation d'une condition, mais que, malgré tout, on vérifie à chaque fois si l'instanciation a été faite ou non. Si un programme sait qu'il devra instancier le singleton, le temps utilisé à valider que l'instanciation ait eu lieu (ou non) est une perte sèche, et on privilégiera d'autres stratégies.

class X {
   // pointeur vers le singleton
   static X *singleton;
   X(); // constructeur privé
public:
   // pour obtenir l'singleton
   static X *get()    {
      //
      // instanciation unique garantie, du moins si
      // le programme n'a qu'un seul fil d'exécution;
      // si votre programme comprend plusieurs fils
      // d'exécution, ce qui suit est insuffisant
      //
      if (!singleton)
         singleton = new X;
      return singleton;
   }
   // ...
};
// initialisation du pointeur de singleton à zéro
// (insérer dans le .cpp)
X *X::singleton = nullptr;

Parenthèse – empêcher la copie

Un vrai singleton ne peut être dupliqué, et doit donc être implémenté de manière à ce que toute tentative de le copier soit illégale. Pour arriver à ce niveau de protection et de confiance, il importe d'empêcher les deux opérations permettant la copie d'un objet et qui ont une implémentation par défaut si on les néglige, soit l'opérateur d'affectation (opérateur =) et le constructeur par copie.

class X {
   static X *singleton; // pointeur vers le singleton
   X(); // constructeur privé
public:
   X(const X&) = delete;
   X& operator=(const X&) = delete;
   static X *get() { // pour obtenir le singleton
      if (!singleton) // voir plus haut
         singleton = new X;
      return singleton;
   }
   // ...
};
// initialisation du pointeur de singleton à zéro
// (insérer dans le .cpp)
X *X::singleton = nullptr;

Approche 1 – membre de classe et instanciation au lancement

Cette approche ressemble à la précédente, à ceci près que l'instanciation du singleton se fait dès le lancement du programme (à l'initialisation du membre de classe singleton).

Avec cette solution, chaque appel à get() sera plus rapide que dans l'approche 0, aucun test n'étant requis sur le pointeur vers le singleton, mais singleton sera allouée qu'on s'en serve ou non.

#include "Incopiable.h"
class X : Incopiable {
   static X *singleton; // pointeur vers le singleton
   X(); // constructeur privé
public:
   static X *get() noexcept { // pour obtenir le singleton
      return singleton;
   }
   // ...
};
// initialisation du pointeur de singleton à zéro
// (insérer dans le .cpp)
X *X::singleton = new X;

Le défaut de cette stratégie est que l'objet ainsi créé (le singleton) ne sera jamais finalisé, au sens où son destructeur ne sera jamais appelé – un objet créé avec new doit être détruit avec delete).

La mémoire associée au singleton sera libérée, bien entendu, à la mort du programme. Cela dit, dans le cas où des opérations spécifiques seraient faites lors d'une invocation du destructeur (fermeture d'un lien de communication, d'une connexion à une BD, libération d'une DLL chargée manuellement, etc.) alors celles-ci ne seront pas réalisées.

Cette stratégie est donc à déconseiller, du moins si on la prend telle quelle.

Approche 2 – membre de classe et instanciation statique

Cette approche est identique à la précédente, sauf pour le fait que le singleton n'est pas alloué dynamiquement et que, conséquemment, on prendra soin de donner accès à son adresse seulement (pas question d'en créer une copie par accident, après tout!). Cette stratégie s'applique aussi en retournant une référence à l'instance en question.

#include "Incopiable.h"
class X : Incopiable {
   static X singleton; // déclaration du singleton
   X(); // constructeur privé
public:
   static X *get() noexcept { // pour obtenir le singleton
      return &singleton;
   }
   // ...
};
// définition du singleton
// (insérer dans le .cpp)
X X::singleton;

Mieux encore, sur le plan de l'utilisation : retourner une référence au singleton.

#include "Incopiable.h"
class X : Incopiable {
   static X singleton; // déclaration du singleton
   X(); // constructeur privé
public:
   static X &get() noexcept { // pour obtenir le singleton
      return singleton;
   }
   // ...
};
// définition du singleton
// (insérer dans le .cpp)
X X::singleton;

Notez qu'il est essentiel ici que le destructeur soit public, sinon le compilateur ne pourra pas finaliser le singleton à la fin de l'exécution du programme donc le programme ne compilera pas.

Approche 3 – variable statique locale à une méthode

Dans cette approche, le singleton n'existera réellement que dans la méthode que y donne accès. La variable qu'est le singleton sera localisée au même endroit que les variables globales du programme mais ne sera visible que de l'intérieur du sous-programme où elle est déclarée.

Le singleton singleton est instancié lors du premier appel à get(), comme dans l'approche 0 proposée plus haut.

L'adresse rendue disponible reste valide tout au cours de l'exécution du programme parce que la variable est statique (au sens du langage C). Il y a un léger coût en performance ici lors de chaque invocation de la méthode get() (le code machine doit sauter par-dessus le code d'initialisation lors des appels suivant le tout premier, ce qui introduit un très léger ralentissement en pratique). Remarquez que la clause noexcept apposée à X::get() dans certaines approches ne peut être utilisée ici (sauf bien sûr si X::X() est aussi noexcept) du fait que le premier appel à X::get(), contrairement aux appels subséquents, construira le singleton.

#include "Incopiable.h"
class X : Incopiable {
   X(); // constructeur privé
public:
   static X &get() { // pour obtenir le singleton
      // Instanciation au premier appel seulement
      static X singleton;
      return singleton;
   }
   // ...
};

Ici, le destructeur n'a pas à être public, car la construction du singleton se fait à même l'une de ses propres méthodes.

Risques d'accès concurrents

Les programmes qui font affaire avec un singleton sont souvent multiprogrammés, par exemple à l'aide de fils d'exécution concurrents (de threads).

Sans entrer dans les détails, tout processus – tout programme en cours d'exécution – est composé d'un ou de plusieurs fils d'exécution – d'un ou de plusieurs threads. Un même processus peut donc être fait de plusieurs threads distincts, qui s'exécutent de manière concurrente.

Lorsqu'un programme muni d'un singleton est fait de plusieurs threads, il existe un risque bien réel que deux d'entre eux tentent d'accéder au singleton pendant une même tranche de temps. Si cela se produit, un risque d'accès concurrent aux données du singleton peut se produire – et un accès concurrent peut mener à une violation de partage si deux des accès tentés sont des accès en écriture, donc qui tentent de modifier une même donnée.

Les violations de partage peuvent faire planter un programme, et sont un problème de la vie courante dans les systèmes multiprogrammés. Mêler threads et singletons demande une saine dose de prudence.

Singletons et interdépendances

Certaines stratégies de singletons créent le singleton lors de la première demande faite pour ses services; d'autres créent le singleton avant même le démarrage du thread principal d'un programme (de la fonction main()).

#include "Incopiable.h"
class A : Incopiable {
   static A singleton;
   A () {
      // ...
   }
public:
   static A &get() noexcept {
      return singleton;
   }
   // ...
};
class B : Incopiable {
   static B singleton;
   B() {
      // ...
   }
public:
   static B &get() noexcept {
      return singleton;
   }
   // ...
};
class C : Incopiable {
   static C singleton;
   C() {
      // ...
   }
public:
   static C &get() noexcept {
      return singleton;
   }
   // ...
};
// dans le ou les fichier(s) source
A A::singleton;
B B::singleton;
C C::singleton;
// ...

Les dépendances entre singletons sont aussi dommageables à la construction qu'à la destruction. On oublie souvent ce détail. La prudence est de mise.

#include "Incopiable.h"
class SingX : Incopiable {
   friend class Ges;
   SingX() = default;
public:
   int f() const {
      return 3;
   }
};
class SingY : Incopiable {
   friend class Ges;
   SingY() = default;
public:
   int g() const {
      return 4;
   }
};
class Ges : Incopiable {
   SingX *pX;
   SingY *pY;
   void creer() {
      //
      // contrôler l'ordre de construction
      //
      pY = new SingY;
      try {
         pX = new SingX;
      } catch (...) {
         delete pY;
         throw;
      }
   }
   void detruire() noexcept {
      //
      // contrôler l'ordre de destruction
      //
      delete pX;
      delete pY;
   }
   Ges() {
      creer();
   }
public:
   static Ges& get() {
      static Ges sing;
      return sing;
   }
   template <class T>
      static T& obtenir();
   template <>
      static SingX& obtenir<SingX>() {
         return *(get().pX);
      }
   template <>
      static SingY& obtenir<SingY>() {
         return *(get().pY);
      }
   ~Ges() {
      detruire();
   }
};
template <class T>
   T &obtenir()
      { return Ges::get().obtenir<T>(); }
int main()
{
   int i = obtenir<SingX>().f();
}

Complément à l'approche 1 – automatiser la destruction du singleton

#include "Incopiable.h"
class X : Incopiable {
   class GestionnaireDeX {
      X *singleton;
   public:
      GestionnaireDeX() : singleton { new X } {
      }
      ~GestionnaireDeX() {
         delete singleton;
      }
      X *get() {
         return singleton;
      }
   };
   static GestionnaireDeX gX;
   X(); // constructeur privé
public:
   // pour obtenir indirectement l'singleton
   static X *get() noexcept {
      return gX.get();
   }
};
// instanciation du singleton (dans le .cpp)
X::GestionnaireDeX X::gX;

Exemple concret – un générateur de nombres aléatoires

Imaginons qu'on veuille faciliter l'accès à des nombres pseudo-aléatoires, de manière à ce que le générateur soit correctement initialisé dans chaque programme y ayant recours et de manière à ce qu'obtenir un nombre pigé pseudo-aléatoirement entre deux bornes soit un service clairement défini. Ce type d'opération est relativement fréquent, et on peut se demander s'il n'y aurait pas lieu de l'implémenter proprement par des objets.

Le fait qu'un générateur de nombres pseudo-aléatoires doive être initialisé une fois par programme seulement est un indice qu'un singleton pourrait y trouver une application intéressante.

Le code irait comme suit.

#include "Incopiable.h"
#include <random>
class BornesInvalides {}; // pour piger()
// Nom savant, idée simple :)
class GenerateurStochastique : Incopiable {
   static GenerateurStochastique singleton;
   GenerateurStochastique() noexcept;
   std::mt19937 prng;
public:
   using value_type = unsigned int; // type public interne
   static GenerateurStochastique &get() noexcept {
      return singleton;
   }
   value_type piger(value_type b_min, value_type b_max) const;
};

#include "GenerateurStochastique.h"
#include <random>
using namespace std;

GenerateurStochastique GenerateurStochastique::singleton;

GenerateurStochastique::GenerateurStochastique() noexcept {
   random_device rd;
   prng = mt19937{rd()};
}
auto GenerateurStochastique::piger(value_type b_min, value_type b_max) const -> value_type {
   if (b_max < b_min) throw BornesInvalides{};
   uniform_int_distribution<> de{ b_min, b_max };
   return de(prng);
}

Un exemple d'utilisation en serait celui-ci, qui tire puis affiche une combinaison de la 6/49 qui sera triée et sans redondance.

#include "GenerateurStochastique.h"
#include <vector>
#include <algorithm>
#include <iterator>
#include <iostream>
int main() {
   using namespace std;
   //
   // Pour alléger l'écriture
   //
   using value_type = GenerateurStochastique::value_type;
   const value_type
      NB_CHIFFRES = 6,
      BORNE_MIN = 1,
      BORNE_MAX = 49;
   vector<value_type> combinaison;
   while(combinaison.size() < NB_CHIFFRES) {
      auto nombre = GenerateurStochastique::get().piger(BORNE_MIN, BORNE_MAX);
      if (find(begin(combinaison), end(combinaison), nombre) == end(combinaison))
         combinaison.push_back(nombre);
   }
   sort(begin(combinaison), end(combinaison));
   cout << "Tirage de la " << NB_CHIFFRES << "/" << BORNE_MAX << ": ";
   copy(begin(combinaison), end(combinaison), ostream_iterator<value_type>{cout, " "});
}

Les aléas de l'optimisation

Un compilateur C++ de qualité tend à procéder à plusieurs optimisations agressives. Parmi ces optimisations, on peut en trouver certaines qui entrent directement en conflit avec la vocation de certaines applications du schéma de conception singleton.

#ifndef CHARGEUR_SOCKETS_H
#define CHARGEUR_SOCKETS_H
#include "Incopiable.h"
class ChargeurSockets : Incopiable {
   static ChargeurSockets singleton;
   ChargeurSockets() noexcept;
public:
   ~ChargeurSockets();
};
#endif

#include "ChargeurSockets.h"
#include <winsock2.h>
// Définition du singleton
ChargeurSockets ChargeurSockets::singleton;
// Code (simplifié, sans traitement d'erreur)
ChargeurSockets::ChargeurSockets() noexcept {
   WSADATA wsaData { 0 };
   WSAStartup(MAKEWORD(2,2), &wsaData);
}
ChargeurSockets::~ChargeurSockets() {
   WSACleanup();
}

#ifndef CHARGEUR_SOCKETS_H
#define CHARGEUR_SOCKETS_H
#include "Incopiable.h"
class ChargeurSockets : Incopiable {
   static ChargeurSockets singleton;
   ChargeurSockets() noexcept;
public:
   static ChargeurSockets &get() noexcept {
      return singleton;
   }
   ~ChargeurSockets();
};
#endif

#include "ChargeurSockets.h"
// Classe soigneusement choisie et dépendant des
// sockets, donc de la création du singleton
class SocketBase {
   // ... bla bla ...
private:
   // pointeur sur une méthode retournant une référence à
   // un GestionnaireSockets et ne prenant aucun paramètre...
   // très exactement comme ChargeurSockets::get()
   static GestionnaireSockets& (*pPatch)();
   // ... bla bla ...
};

#include "SocketBase.h"
GestionnaireSockets& (*SocketBase::pPatch)() =
   GestionnaireSockets::get;
// ...

#include "ChargeurSockets.h"
// Classe soigneusement choisie et dépendant des
// sockets, donc de la création du singleton
class SocketBase {
   // ... bla bla ...
private:
   //
   // on prend l'adresse de ChargeurSockets::get(),
   // sans l'appeler
   //
   SocketBase() {
      auto patch = GestionnaireSockets::get;
      // ... bla bla ...
   }
   // ... bla bla ...
};

Variante sur l'implémentation du schéma de conception Singleton

Imaginons que l'approche 03 ait été choisie pour implémenter un singleton mais qu'on souhaite faire en sorte de réduire la quantité de code redondant à écrire pour chaque singleton. L'idée, donc, est de réduire le code de service du singleton à sa plus simple expression, idéalement un constructeur privé, un destructeur privé et des méthodes d'singleton.

#include "Incopiable.h"
template <class S>
   struct Singleton : Incopiable {
      static S& get() {
         static S singleton;
         return singleton;
      }
   };
//
// Ceci est un exemple pour démontrer la technique
//
class Service : Singleton<Service> { // magie!
   // sans ceci, le parent ne peut instancier son enfant
   friend class Singleton<Service>;
   Service() : cur{} {
      // bla bla
   }
   ~Service() noexcept {
      // bla bla
   }
   int cur;
public:
   // vos services vont ici
   int prochain() noexcept {
      return ++cur;
   }
};
//
// Ta-daaa: ça marche!
//
#include <iostream>
int main() {
   using std::cout;
   auto &service = Singleton<Service>::get();
   for (int i = 0; i < 10; ++i)
      cout << service.prochain() << ' ';
} 

Où est le singleton?

Il y a une subtilité dans le choix des termes avec une approche un peu hors-normes comme la variante ci-dessus, du moins si l'on souhaite l'expliquer en utilisant un vocabulaire proche des usages plus classiques en POO.

class Service : Singleton<Service> {
   friend class Singleton<Service>;
   Service();
   // ...
};

D'un regard technique, on peut constater que Singleton<Service>::get() est en fait une fonction globale, qualifiée par le type de ce qui doit être fabriqué. En dérivant Service de Singleton<Service>, on a surtout enrichi l'espace global d'une fonctionnalité spécialisée pour instancier Service dans le respect du schéma de conception.

Une autre raison de prendre cette manoeuvre comme une annotation plutôt que de la considérer comme étant une application de l'héritage est que le nom du parent (pris en tant que parent) est trompeur. Un singleton, selon l'acception stricte du concept, ne peut pas avoir d'enfants : en POO, en effet, un enfant est aussi en partie son parent, alors le singleton-comme-parent ne serait plus un singleton. Par contre, ici, le singleton est Service, pas Singleton<Service> (c'est là la subtilité de la manoeuvre). C'est pourquoi j'estime sage de considérer cette application de l'héritage privé et de l'idiome CRTP comme une annotation intelligente de l'enfant; cela me semble être une interprétation plus juste de cette variante, malgré les apparences.

La question de l'ordre de destruction des singletons

Ce qui suit a été rédigé de prime abord pour répondre aux questions du sympathique Jérôme Rampon, en lien avec l'impossibilité a priori d'établir à même le code source l'ordre de destruction de variables globales (dont les singletons) lorsque celles-ci sont disséminées dans divers fichiers sources.

Allons-y d'un exemple. Soit les classes suivantes :

#ifndef X_H
#define X_H
//
// Fichier X.h
//
#include "Incopiable.h"
class X : Incopiable {
   X() = default;
public:
   static X &get() {
      static X singleton;
      return singleton;
   }
   ~X();
   int f();
};
#endif

#ifndef Y_H
#define Y_H
//
// Fichier Y.h
//
#include "Incopiable.h"
class Y : Incopiable {
   int val;
   Y();
public:
   static Y &get() {
      static Y singleton;
      return singleton;
   }
   ~Y();
   int f();
};
#endif

#ifndef Z_H
#define Z_H
//
// Fichier Z.h
//
#include "Incopiable.h"
class Z : Incopiable {
   int val;
   Z();
public:
   static Z &get() {
      static Z singleton;
      return singleton;
   }
   ~Z();
   int f();
};
#endif

//
// Fichier X.cpp
//
#include "X.h"
#include <iostream>
using namespace std;
X::~X() {
   // Voir la note, plus bas
   cout << "Destructeur de X"
        << endl;
}
int X::f()
   { return 3; }

//
// Fichier Y.cpp
//
#include "Y.h"
#include "X.h"
#include <iostream>
using namespace std;
Y::Y() : val(X::get().f()) {
}
Y::~Y() {
   // Voir la note, plus bas
   cout << "Destructeur de Y"
        << endl;
}
int Y::f()
   { return 2 * val; }

//
// Fichier Z.cpp
//
#include "Z.h"
#include "X.h"
#include <iostream>
using namespace std;
Z::Z() : val(X::get().f()) {
}
Z::~Z() {
   // Voir la note, plus bas
   cout << "Destructeur de Z"
        << endl;
}
int Z::f()
   { return -val; }

Ici, présumant le code découpé en six fichiers tel qu'indiqué ci-dessus, on sait que :

• L'instance unique de X sera instanciée avant que le constructeur de Y ne se complète, puisque la méthode X::get() est appelée dans Y::Y() et puisque le singleton X est qualifié static dans X::get()
• De même, l'instance unique de X sera instanciée avant que le constructeur de Z ne se complète, puisque la méthode X::get() est appelée dans Z::Z() et puisque le singleton X est qualifié static dans X::get()
• On ne connaît pas au préalable l'ordre d'instanciation de Y et de Z. Cet ordre dépendra de l'ordre d'appel de Y::get() et de Z::get() dans le code client; il est même possible que ces deux singletons ne soient jamais instanciés, dans la mesure où ni Y::get(), ni Z::get(), pas plus que X::get() (bien entendu) ne seraient appelées
• Surtout, on ne connaît pas l'ordre d'appel de X::~X(), Y::~Y() et Z::~Z(). Cette partie dépend de conditions extérieures au code source
• Notez que nous ne savons même pas si std::cout sera détruit avant ou après les appels à X::~X(), Y::~Y() ou Z::~Z() (avant les trois? après les trois? entre deux d'entre eux?). Tous les quatre sont des objets globaux et nous ne contrôlons pas l'ordre de leur destruction

Le compilateur compile chaque .cpp séparément, alors que les conditions propres à l'ordre d'instanciation ou de destruction des variables globales sont des considérations transversales, qui dépendent de plusieurs fichiers sources distincts. Voilà la racine du problème.