Code de grande personne – Garantir l'ordre de création/ destruction des singletons statiques en C++

Les singletons ne sont pas une panacée mais constituent un schéma de conception utile pour résoudre une gamme de problèmes spécifique, soit tous les cas il est nécessaire de garantir qu'un processus ne contienne qu'une seule instance d'une classe donnée.

Un problème de fond

Il est possible de découper les singletons en deux grandes familles :

• Les singletons statiques, créés avant même le début de l'exécution de la fonction main() et détruits après la fin de l'exécution de cette fonction. Dans l'article sur les singletons, l'approche 2 et le complément à l'approche 1, cette dernière de façon détournée, sont de cette catégorie, et
• Les singletons dynamiques, qui sont créés lors de leur première utilisation. Dans l'article sur les singletons, l'approche 0 est de cette catégorie.

Le problème des singletons statiques est que chaque singleton est, en fait, une variable globale, et qu'il n'est pas possible a priori de garantir l'ordre de construction ou l'ordre de destruction des variables globales d'un projet lorsqu'elles sont disséminées dans plusieurs fichiers binaires.

Cela signifie qu'il n'est pas possible, du moins de l'avis de plusieurs, de concevoir (de manière générale) des singletons statiques dépendant d'autres singletons statiques. Ainsi, il est impossible de prévoir un design dans lequel un singleton A utilise les services d'un singleton B si on n'arrive pas à garantir que B sera construit avant A et que B sera détruit après A.

Ce problème limite l'utilité des singletons statiques. On n'a qu'à penser à un singleton chargeant d'une base de données des paramètres propres au fonctionnement d'un programme: si nous n'arrivons pas à garantir que ce singleton sera créé avant ceux qui utilisent ces paramètres, et si nous n'arrivons pas à garantir que ce singleton sera détruit après ceux qui en dépendent, alors nous devons envisager une stratégie plus manuelle, moins élégante que celle exploitant la dualité constructeur/ destructeur du singleton pour automatiser le chargement des paramètres et leur entreposage en fin de parcours.

Plusieurs experts, en particulier Andrei Alexandrescu dans son excellent volume Modern C++ Design, prétendent qu'assurer un ordre entre la création et la destruction de singletons statiques est un problème insoluble en C++. à partir de ce constat, ils concentrent leurs efforts sur les singletons dynamiques, ce qui (nous le verrons) est une erreur, au sens où cela introduit des difficultés qu'il faut contourner à l'aide de stratégies problématiques et au sens où cela ne permet pas de remplacer les singletons statiques aux endroits et dans les situations où ils sont utiles.

Nous utiliserons d'ailleurs certaines idées mises de l'avant par Alexandrescu pour résoudre de manière générale le problème de l'ordonnancement de singletons interdépendants.

Les singletons dynamiques – en quoi ils aident et en quoi ils nuisent

Le problème des singletons dynamiques est double.

#ifndef GENERATEUR_SEQUENCE_H
#define GENERATEUR_SEQUENCE_H
#include <memory>
class GenerateurSequence {
   int prochain_ = 0;
   static std::unique_ptr<GenerateurSequence> singleton;
   GenerateurSequence() = default;
public:
   GenerateurSequence(const GenerateurSequence &) = delete;
   GenerateurSequence& operator=(const GenerateurSequence &) = delete;
   static std::unique_ptr<GenerateurSequence> &get() {
      if (!singleton) // condition de course!
         singleton = std::unique_ptr<GenerateurSequence>{new GenerateurSequence};
      return singleton;
   }
   int prochain() noexcept {
      return prochain_++;
   }
};
#endif

// GenerateurSequence.cpp
#include "GenerateurSequence.h"
#include <memory>
using namespace std;
unique_ptr<GenerateurSequence> GenerateurSequence::singleton;

#ifndef GENERATEUR_SEQUENCE_H
#define GENERATEUR_SEQUENCE_H
#include <mutex>
#include <atomic>
class GenerateurSequence {
   static std::mutex verrou;
   std::atomic<int> prochain_ { 0 };
   static std::unique_ptr<GenerateurSequence> singleton;
   GenerateurSequence() = default;
public:
   GenerateurSequence(const GenerateurSequence &) = delete;
   GenerateurSequence& operator=(const GenerateurSequence &) = delete;
   static GenerateurSequence *get() {
      if (!singleton) {
         std::lock_guard<std::mutex> av{verrou};
         if (!singleton)
            singleton = std::unique_ptr<GenerateurSequence>{new GenerateurSequence};
      }
      return singleton;
   }
   int prochain() noexcept {
      return prochain_++;
   }
};
#endif

// GenerateurSequence.cpp
#include <memory>
using namespace std;
unique_ptr<GenerateurSequence> GenerateurSequence::singleton;

Utiliser des singletons dynamiques règle le problème de l'ordre de construction des singletons : un singleton est alors créé lors de sa première utilisation, donc qu'un singleton dépende d'un autre entraînera nécessairement une séquence de création dans le bon ordre. Cependant, les singletons créés ainsi ne seront pas détruits correctement, au sens où leur destructeur ne sera pas invoqué du tout ou ne sera pas invoqué selon un ordre prévisible.

Parenthèse sur les singletons en tant que variables statiques à une méthode

#ifndef GENERATEUR_SEQUENCE_H
#define GENERATEUR_SEQUENCE_H
#include <atomic>
class GenerateurSequence {
   std::atomic<int> prochain_{ 0 };
   GenerateurSequence() = default;
public:
   GenerateurSequence(const GenerateurSequence &) = delete;
   GenerateurSequence& operator=(const GenerateurSequence &) = delete;
   static GenerateurSequence &get() {
      static GenerateurSequence singleton;
      return singleton;
   }
   int prochain() noexcept {
      return prochain_++;
   }
};
#endif

Hypothèses derrière notre statégie

Nous proposerons ici une stratégie garantissant un ordre de construction entre singletons lorsque certains d'entre eux dépendent d'autres singletons. Nous présumerons qu'une vision applicative existe qui permette de décider, d'une manière externe aux singletons eux-mêmes, les dépendances entre les singletons, donc que cette responsabilité soit systémique, un point de design général pour un programme donné.

Notre stratégie réglera à la compilation le problème de l'ordre de création des singletons statiques. Elle réglera aussi à la compilation le probleme de l'ordre de destruction des singletons statiques. Elle réglera à l'exécution le problème du caractère unique des singletons, mais nous expliquerons plus loin pourquoi ce problème ne peut être réglé à la compilation; il peut être réglé lors de l'édition des liens, mais je suis certain que ma solution est perfectible.

Démarche

Je démontrerai d'abord la stratégie de manière générale, avec des singletons nommés SingletonA et SingletonB. J'expliquerai comment adapter le schéma de conception traditionnel du singleton pour appliquer notre stratégie et je montrerai en quoi la proposition faite ici n'est rien d'autre qu'une application du schéma de conception traditionnel et ne corrompt pas ce schéma.

Je montrerai comment il est possible de garantir que SingletonA soit construit avant SingletonB et que SingletonA soit détruit après SingletonB. Je montrerai aussi comment changer cet ordre sans modifier de manière adverse les singletons SingletonA et SingletonB eux-mêmes. Enfin, je montrerai comment étendre la stratégie à un nombre arbitrairement grand de singletons (de types différents, par définition).

Je montrerai ensuite comment faire en sorte que la contrainte d'unicité du singletons soit respectée dans la mesure où le schéma de conception tel que nous l'implémentons ici est respecté. J'expliquerai pourquoi il devient difficile (peut-être même impossible) de valider cette contrainte à la compilation, pourquoi j'estime en retour possible d'envisager un stratagème validant la contrainte d'unicité à l'édition des liens, et pourquoi je considère acceptable (bien qu'irritant d'un point de vue esthétique) de valider la contrainte à l'exécution comme je le fais ici.

Je proposerai alors un exemple plus concret (bien que simple) de singletons entre lesquels il existe une dépendance pour situer la stratégie dans un cadre plus concret.

Enfin, je discuterai de la stratégie générale utilisée pour résoudre le problème et d'avenues pour l'appliquer à d'autres problèmes. Je montrerai dans quelle mesure la stratégie est sécuritaire (ou, du moins, n'est pas moins sécuritaire que les approches reposant sur des singletons dynamiques) dans un contexte multiprogrammé.

Puisque j'avais une solution opérationnelle avec C++ 03 et puisque la solution que j'ai avec C++ 11 est plus jolie, les deux seront présentées côte à côte. Si votre compilateur est à jour, préférez (de loin!) la version C++ 11.

Rappel du problème

Il y a des raisons de souhaiter des singletons statiques. Cependant, il peut arriver qu'il existe un lien de dépendance entre plusieurs singletons, ce qui suggère qu'il faille être en mesure de forcer entre eux un ordre de création et un ordre de destruction, l'un étant généralement l'inverse de l'autre.

Parmi les cas typiques de singletons dont d'autres singletons peuvent dépendre, on trouve :

• Un singleton servant à établir une connexion à une base de données (BD) et permettant à d'autres objets (incluant des singletons) d'accéder à cette BD
• Un singleton servant à initialiser a priori un générateur de nombres aléatoires, évitant ainsi l'insertion de code initialisant manuellement ce générateur
• Un singleton assurant dans son constructeur le chargement au préalable d'un module de support et déchargeant ce module dans son destructeur (pensez à WSAStartup() et à WSACleanup() pour charger et décharger les sockets sous Microsoft Windows), etc.

Dans tous ces cas, utilisés avec soin, le recours à un singleton pour automatiser les a priori et les a posteriori d'un programme évite de répéter (de manière erronnée) certaines opérations, ce qui réduit les risques d'accidents. Par exemple, on réduit ainsi le risque de double déchargement d'un module de support ou le risque d'oubli de procéder à certaines initialisations.

Le problème demeure d'ordonnancer les opérations à effectuer a priori et a posteriori. La solution traditionnelle passant par des singletons dynamiques est incomplète, ne couvrant pas de manière élégante l'ordonnancement de la destruction des singletons, et lente pour les applications qui auront fréquemment recours au service d'accès à un singleton, ajoutant chaque fois un test supplémentaire (ce qui, en particulier, réduit la capacité du processeur de garder plein son pipeline d'instructions).

Une piste de solution

Le problème pourrait être solutionné en fusionnant tous les singletons statiques de manière à ce qu'ils soient tous des attributs d'une même classe, elle-même un singleton statique. Procédant ainsi, l'application du schéma de conception singleton se déplacerait des singletons individuels à leur conteneur, qui pourrait avoir droit à ce privilège par amitié.

#ifndef CONTENEUR_SINGLETONS_H
#define CONTENEUR_SINGLETONS_H
class SingletonA {
   SingletonA() {
      // ...
   }
public:
   SingletonA(const SingletonA&) = delete;
   SingletonA& operator=(const SingletonA&) = delete;
   //
   // services du singleton (...)
   //
   friend class ConteneurSingletons;
};
//
// Idem pour SingletonB (omis par économie)
//
class ConteneurSingletons {
   SingletonA singA {};
   SingletonB singB {};
   ConteneurSingletons() = default;
public:
   ConteneurSingletons(const ConteneurSingletons&);
   ConteneurSingletons& operator=(const ConteneurSingletons&);
   static ConteneurSingletons &get() {
      static ConteneurSingletons singleton;
      return singleton;
   }
   SingletonA& getA() const {
      return singA;
   }
   SingletonB& getB() const {
      return singB;
   }
};
#endif

Cette stratégie va comme suit :

• Chaque singleton prospectif dira d'une classe destinée à lui servir de conteneur qu'elle est son ami
• Chaque singleton prospectif sera incopiable et offrira un constructeur (probablement dans sa déclinaison par défaut) privé
• Le schéma de conception singleton sera implémenté par le conteneur seulement
• Étant l'ami de chaque singleton prospectif, le conteneur de singletons aura le droit de les instancier. N'ayant qu'un seul attribut pour chaque type de singleton prospectif et étant lui-même un singleton, le conteneur assure par sa propre existence (en collaboration avec les types de ses attributs) l'unicité de chaque singleton prospectif
• Chaque singleton prospectif devient alors un singleton de facto
• Enfin, l'accès à chaque singleton de facto du conteneur passe par une double indirection (obtention d'une référence sur le conteneur puis sur le singleton désiré), mais le method inlining peut éliminer entièrement le poids de cette double indirection dans bien des cas

Cette stratégie fonctionnerait parce que le standard de C++ définit l'ordre de construction et l'ordre de destruction des attributs d'un objet. Cependant, cet ordre est contre-intuitif pour bien des gens puisqu'il correspond à l'ordre de déclaration des attributs, sujet à être différent de l'ordre de préconstruction des attributs : exprimé autrement, ici, singA est construit avant singB puis détruit après singB simplement parce que dans ConteneurSingletons, singA est déclaré avant singB. C'est une approche quelque peu fragile; règle générale, on s'abstiendra de faire reposer du code sur des considérations obscures comme celle-ci, à moins bien sûr qu'il n'y ait pas d'autres options (et, dans ce cas, on prendra soin de documenter la manoeuvre). Le coût associé à l'entretien du code obscur est souvent si élevé que le retour sur l'investissement est, disons-le à la blague, négatif.

Pour contrôler l'ordre de création et de destruction des singletons de facto que sont singA et singB, on pourrait les créer et les supprimer manuellement, avec new et delete, mais cela entraînerait son propre lot d'irritants. Nous préférerions éviter d'échanger une série d'ennuis pour une autre.

En plus du fait que cette façon de faire repose sur un aspect obscur du standard, elle a comme défaut d'être intrusive et d'exiger des ajustements fréquents au code, deux irritants du point de vue de son entretien :

• Chaque singleton prospectif doit spécifier que le conteneur de singletons est son ami, ce qui en soi ne pose pas de problème. En effet, implémenter le schéma de conception localement ou spécifier son inclusion dans un conteneur garantissant son unicité est ici porteur du même sens
• En retour, le conteneur de singletons contient du code spécifique à la combinaison de singletons de facto qu'il rassemble sous son égide, incluant des noms distincts pour les attributs et pour les méthodes d'accès
• De même, le code client du conteneur de singletons (et des singletons eux-mêmes) doit être adapté noms des méthodes du conteneur de singletons

Enfin, comme la plupart des stratégies manuelles, celle-ci alourdit beaucoup la tâche de développement, augmente la probabilité d'erreurs humaines et est difficile à généraliser autrement que par simple discipline humaine. Ajouter à cela le facteur obscur de la règle indiquant l'ordre de l'inialisation des attributs montre que nous ne pouvons nous arrêter ici et prétendre proposer une stratégie générale.

Il y a de l'espoir

Tout n'est pas sombre, cela dit :

• L'idée d'implémenter le schéma de conception à l'aide d'un conteneur est solide si on parvient à l'exprimer sous une forme plus générique (nous verrons sous peu comment)
• L'idée de grouper plusieurs singletons dans un seul conteneur est aussi solide si le code pour y arriver peut être généralisé et devient moins dépendant de manipulations à la pièce, enfin
• Il existe des manières beaucoup moins obscures pour forcer un ordre de construction entre instances de classes distinctes que celle utilisée ici et reposant sur l'ordre de construction des attributs d'un objet. En particulier, nous savons que la mécanique de l'héritage est telle que pour toute instance X d'une classe Derivee dérivant d'une classe Base, la partie Base de X sera construite avant sa partie Derivee et la partie Derivee de X sera détruite avant sa partie Base

Les clés de la généralisation dans un problème comme celui-ci nous sont données par les travaux de pionniers de la programmation générique comme Andrei Alexandrescu (listes de types) et messieurs Barton et Nackman (pour le truc du même nom).

Nous ne retiendrons, pour notre argumentaire, que les idées essentielles des concepts sur lesquels nous bâtirons notre stratégie. Vous serez invité(e) à (re)lire les articles spécifiques à chacune de ces idées pour avoir plus de détails à son sujet.

Implémentation concrète

#ifndef GENERATEURSEQUENTIEL_H
#define GENERATEURSEQUENTIEL_H
#include "Intervalle.h"
#include "Sequence.h"
#include "SingletonWrapper.h"
template <class T, class Interv = Intervalle<T>>
   class GenerateurSequentiel : Sequence<T> {
   public:
      using value_type = typename Sequence<T>::value_type;
      GenerateurSequentiel(const GenerateurSequentiel&) = delete;
      GenerateurSequentiel& operator=(const GenerateurSequentiel&) = delete;
   private:
      GenerateurSequentiel(const Interv &bornes = {})
         : Sequence<T>(bornes.minval, bornes.maxval)
      {
      }
      friend struct SingletonWrapper<GenerateurSequentiel<T, Interv>>;
   public:
      value_type prochain() {
         auto valeur = curval();
         prochaine_valeur();
         return valeur;
      }
   };
#endif

#ifndef INTERVALLE_H
#define INTERVALLE_H
#include <limits>
class BornesInvalides {};
class ValeurIncoherente {};
template <class T>
   struct Intervalle {
      using value_type = T;
      const value_type minval = std::numeric_limits<value_type>::min();
      const value_type maxval = std::numeric_limits<value_type>::max();
      constexpr bool est_inclus(const value_type &val) const {
         return minval <= val && val <= maxval;
      }
      Intervalle() = default;
      constexpr Intervalle(const value_type &minval)
         : minval{ minval }, maxval{ std::numeric_limits<value_type>::max() }
      {
      }
      constexpr Intervalle(const value_type &minval, const value_type &maxval)
         : minval{ minval },
           maxval{ (minval > maxval)? throw BornesInvalides{} : maxval } 
      {
      }
   };
#endif

#ifndef SEQUENCE_H
#define SEQUENCE_H
#include "Intervalle.h"
template <class T>
   class Sequence {
   public:
      using value_type = T;
   private:
      Intervalle intvl;
      value_type cur;
   public:
      Sequence(const value_type &minval, const value_type &maxval)
         : intvl{ minval, maxval }, cur{ minval }
      {
      }
      value_type curval() const {
         return cur;
      }
      value_type prochaine_valeur() {
         const auto valeur = curval();
         cur = valeur == intvl.maxval ? intvl.minval : cur + 1;
         return valeur;
      }
   };
#endif

#ifndef GENERATEUR_UNIQUE_H
#define GENERATEUR_UNIQUE_H
#include "Intervalle.h"
#include "SingletonWrapper.h"
#include <vector>
class GenerateurUnique {
public:
   using value_type = int;
   GenerateurUnique(const GenerateurUnique&) = delete;
   GenerateurUnique& operator=(const GenerateurUnique&) = delete;
private:
   std::vector<value_type> distribue;
   GenerateurUnique() = default;
   bool contient(value_type) const;
   friend struct SingletonWrapper<GenerateurUnique>;
public:
   value_type prochain();
   void remettre(value_type);
};
#endif

#include "GenerateurUnique.h"
#include "GenerateurStochastique.h"
#include "SingletonDefinition.h"
#include <algorithm>
using namespace std;
bool GenerateurUnique::contient(value_type val) const {
   return find(begin(distribue), end(distribue), val) != end(distribue);
}
auto GenerateurUnique::prochain() -> value_type {
   auto &gen = singletons::get().get_singleton<GenerateurStochastique>();
   auto val = gen.prochain();
   while (contient(val)) // Boucle: O(???)
      val = gen.prochain();
   distribue.push_back(val);
   return val;
}
void GenerateurUnique::remettre(value_type val) {
   if (!contient(val)) throw ValeurIncoherente{};
   remove(begin(distribue), end(distribue), val);
   distribue.shrink_to_fit();
}

#ifndef GENERATEUR_RECYCLEUR_H
#define GENERATEUR_RECYCLEUR_H
#include "Intervalle.h"
#include "Sequence.h"
#include "SingletonContextFwd.h"
#include <deque>
#include <limits>
#include <algorithm>
template <class T>
   class GenerateurRecycleur : Sequence<T> {
   public:
      using value_type = typename Sequence<T>::value_type;
      GenerateurRecycleur(const GenerateurRecycleur&) = delete;
      GenerateurRecycleur& operator=(const GenerateurRecycleur&) = delete;
   private:
      std::deque<value_type> recyclable;
      GenerateurRecycleur() : Sequence<T>(T{}, std::numeric_limits<T>::max()) {
      }
      bool contient(value_type val) const {
         using namespace std;
         return find(begin(recyclable), end(recyclable), val) != end(recyclable);
      }
      friend struct SingletonWrapper<GenerateurRecycleur<T>>;
   public:
      value_type prochain() {
         if (recyclable.empty()) return prochaine_valeur();
         auto val = recyclable.front();
         recyclable.pop_front();
         return val;
      }
      void remettre(value_type val) {
         if (contient(val)) throw ValeurIncoherente{};
         recyclable.push_back(val);
      }
   };
#endif

#ifndef GENERATEURSTOCHASTIQUE_H
#define GENERATEURSTOCHASTIQUE_H
#include "Intervalle.h"
#include "SingletonContextFwd.h"
#include <random>
#include <mutex>
class GenerateurStochastique {
public:
   using value_type = int;
private:
   mutable std::mutex m;
   mutable std::mt19937 prng;
   GenerateurStochastique();
   friend struct SingletonWrapper<GenerateurStochastique>;
public:
   // bornes inclusives
   value_type prochain(const Intervalle<value_type>& = {}) const;
};
#endif

#include "GenerateurStochastique.h"
#include <random>
#include <mutex>
#include <type_traits>
using namespace std;
GenerateurStochastique::GenerateurStochastique() : prng{ random_device{}() }{
}
template <class T>
   struct distribution_type_trait {
      using type = conditional_t<
         is_integral<T>::value, uniform_int_distribution<T>, uniform_real_distribution<T>
      >;
   };
auto GenerateurStochastique::prochain(const Intervalle<value_type> &bornes) const -> value_type {
   distribution_type_trait<value_type>::type de{ bornes.minval, bornes.maxval };
   lock_guard<mutex> _ { m };
   return de(prng);
}

Le recours à une liste de types

#ifndef TYPE_LIST_H
#define TYPE_LIST_H
class Vide {};
template <class T, class U>
   struct type_list;

#ifndef TYPE_LIST_H
#define TYPE_LIST_H
template <class ... >
   struct type_list;
#endif

Nous utiliserons une liste de types pour lister les types de singletons prospectifs. L'ordre des types dans la liste correspondra à l'ordre de construction des singletons et à l'ordre inverse de leur destruction. Ce mécanisme a beaucoup d'avantages. En particulier :

• Si une liste de types suffit à définir l'ordre de construction (et de destruction) des singletons, cela implique que les singletons eux-mêmes peuvent être rassemblés et ordonnancés au besoin par le code client sans que les singletons ne doivent être modifiés à l'interne
• Un programme peut donc spécifier les singletons requis (et l'ordre requis) à partir d'une banque et s'assurer ainsi que l'instanciation effecitve des objets soit limitée à ceux qui seront véritablement utilisés
• Ajouter un singleton au système, si nous parvenons à nos fins, devrait simplement demander de nous l'ajout du nom de son type dans une séquence de types

Implémenter un singleton par délégation envers un ami

Nos singletons prospectifs délégueront la tâche d'implémenter le schéma de conception singleton à un tiers. Je nommerai ce tiers SingletonWrapper, qui sera une classe (en fait, un struct) générique.

#ifndef SINGLETON_WRAPPER_H
#define SINGLETON_WRAPPER_H
template <class>
   class NonRespectSingleton {};
template <class T>
   struct SingletonWrapper {
      static int ninst;
      using type = T;
   private:
      type singleton;
   public:
      SingletonWrapper() {
         if (ninst++) throw NonRespectSingleton<T>();
      }
      type& get() {
         return singleton;
      }
   };
template <class T>
   int SingletonWrapper<T>::ninst = {};
#endif

#ifndef SINGLETON_WRAPPER_H
#define SINGLETON_WRAPPER_H
#include <atomic>
template <class>
   class NonRespectSingleton {};
template <class T>
   struct SingletonWrapper {
      static std::atomic<int> ninst;
      using type = T;
   private:
      type singleton;
   public:
      SingletonWrapper() {
         if (ninst++) throw NonRespectSingleton<T>{};
      }
      type& get() {
         return singleton;
      }
   };
template <class T>
   std::atomic<int> SingletonWrapper<T>::ninst = {};
#endif

Concept utilitaire – le conteneur de singletons

L'étape suivante est de mettre en place une structure par laquelle, à partir une liste de types, on arrivera à assurer la construction et la destruction dans l'ordre souhaité des singletons. La structure que je vous propose mêle liste de types et enchaînement de classes parents dans une hiérarchie de classes génériques par héritage simple où les liens de parenté respectent l'ordre selon lequel apparaissent les types de singletons dans une liste de types donnée.

#ifndef SINGLETON_CONTEXT_H
#define SINGLETON_CONTEXT_H
#include "type_list.h"
#include "SingletonWrapper.h"
template <class>
   class ConteneurSingleton;
template <>
   class ConteneurSingleton<Vide> {
   public:
      Vide& get() {
         static Vide v;
         return v;
      }
   };
template <class T, class Q>
   class ConteneurSingleton<type_list<T, Q>>
      : public ConteneurSingleton<Q>
   {
   public:
      using singleton_type = T;
   private:
      SingletonWrapper<singleton_type> singleton_;
      template <class T>
         T& RecursiveParentGet() {
            return ConteneurSingleton<Q>::get<T>();
         }
   public:
      template <class T>
         T& get() {
            return RecursiveParentGet<T>();
         }
      template <>
         singleton_type& get<singleton_type>() {
            return singleton_.get();
         }
   };
template <class TList>
   class SingletonContext
      : ConteneurSingleton<TList>
   {
      static SingletonContext ctx;
      SingletonContext() = default;
   public:
      SingletonContext(const SingletonContext&) = delete;
      SingletonContext& operator=(const SingletonContext&) = delete;
      static SingletonContext& get() {
         return ctx;
      }
      template <class T>
         T & get_singleton() {
            return ConteneurSingleton<TList>::template get<T>();
         }
   };
template <class TList>
   SingletonContext<TList> SingletonContext<TList>::ctx;
#endif

#ifndef SINGLETON_CONTEXT_H
#define SINGLETON_CONTEXT_H
#include "SingletonWrapper.h"
#include "type_list.h"
#include <type_traits>
template <class T>
   class ConteneurSingleton {
   public:
      T& get() {
         static T singleton;
         return singleton;
      }
   };
template <class T, class ... Q>
   class ConteneurSingleton<type_list<T, Q...>>
      : public ConteneurSingleton<type_list<Q...>>
   {
   public:
      using singleton_type = T;
   private:
      SingletonWrapper<singleton_type> singleton_;
      template <class U>
         U& ParentGet() {
            return ConteneurSingleton<type_list<Q...>>::template get<U>();
         }
      template <class T>
         struct searcher {};
      class Found {};
      class NotFound {};
      template <class U>
         U& search_for(searcher<U>, Found) {
            return singleton_.get();
         };
      template <class U>
         U& search_for(searcher<U>, NotFound) {
            return ParentGet<U>();
         };
   public:
      template <class U>
         U& get() {
            return search_for(searcher<U>{}, std::conditional_t<
               std::is_same<T, U>::value, Found, NotFound
            >{});
         }
   };
template <class TList>
   class SingletonContext : ConteneurSingleton<TList> {
      static SingletonContext ctx;
      SingletonContext() = default;
   public:
      SingletonContext(const SingletonContext&) = delete;
      SingletonContext& operator=(const SingletonContext&) = delete;
      static SingletonContext& get() {
         return ctx;
      }
      template <class T>
         T & get_singleton() {
            return ConteneurSingleton<TList>::template get<T>();
         }
   };
template <class TList>
   SingletonContext<TList> SingletonContext<TList>::ctx;
#endif

Ces propriétés miracles ne sont pas accidentelles. Une invocation pour un type supporté mènera, par une séquence d'invocation de méthodes d'une seule ligne toutes pleinement visibles du compilateur et, par conséquent, toutes pleinement susceptibles de se voir appliquer du Method Inlining. En retour, une invocation pour un type qui n'apparaît pas dans la hiérarchie des diverses incarnations de ConteneurSingleton entraînera une erreur à la compilation.

Notez que nous n'avons toujours pas atteint le seuil visé, soit celui d'une structure telle qu'elle nous permet de garantir l'ordre de construction et de destruction d'une liste arbitraire de singletons statiques. Cependant, nous approchons du but :

• Un singleton prospectif de type T n'a qu'à se rendre impossibles à copier ou à instancier sauf par son seul ami qui est SingletonWrapper<T>
• Un SingletonWrapper<T> instancie et formalise l'accès à un type T donné
• Un ConteneurSingleton<T,Q...> génère une hiérarchie telle que l'enfant est ConteneurSingleton<T> et possède un attribut de type SingletonWrapper<T> et telle que le parent est un ConteneurSingleton<Q...>
• À travers un ConteneurSingleton<T>, la méthode d'instance get<T>() retourne une référence au singleton de type T
• À travers un ConteneurSingleton<T,Q...>, la méthode d'instance get<R>() retourne une référence au singleton de type R si le type R apparaît dans Q... et génère une erreur de compilation dans le cas contraire

Enfin, la liste ordonnancée de singletons

#ifndef SINGLETON_DEFINITION_H
#define SINGLETON_DEFINITION_H
#include "GenerateurStochastique.h"
#include "GenerateurSequentiel.h"
#include "GenerateurUnique.h"
#include "GenerateurRecycleur.h"
#include "type_list.h"
#include "SingletonContext.h"
using les_singletons = type_list<
   GenerateurUnique, type_list<
      GenerateurSequentiel<int>, type_list<
         GenerateurRecycleur<int>, type_list<
            GenerateurStochastique>, Vide
         >
      >
   >
>
using singletons = SingletonContext<les_singletons>;
#endif

#ifndef SINGLETON_DEFINITION_H
#define SINGLETON_DEFINITION_H
#include "GenerateurStochastique.h"
#include "GenerateurSequentiel.h"
#include "GenerateurUnique.h"
#include "GenerateurRecycleur.h"
#include "type_list.h"
#include "SingletonContext.h"
using les_singletons = type_list<
   GenerateurUnique,
   GenerateurSequentiel<int>,
   GenerateurRecycleur<int>,
   GenerateurStochastique
>;
using singletons = SingletonContext<les_singletons>;
#endif

Utiliser le tout

 template <class T>
   T& get_singleton() {
      return singletons::get().get_singleton<T>();
   }

#include "SingletonDefinition.h"
int generer() {
   return singletons::get().get_singleton<GenerateurStochastique>().prochain(Intervalle<int>{-4,-2});
   //return GenerateurRecycleur::get().prochain();
   //return GenerateurUnique::get().prochain();
   //return GenerateurStochastique::get().prochain(Intervalle(-4,-2));
   //return GenerateurSequentiel::get().prochain();
   //return GenerateurUsuel::get().prochain ();
}
void remettre(int val) {
   //GenerateurUnique::get().remettre(val);
   //GenerateurRecycleur<int>::get().remettre(val);
}
#include <iostream>
#include <algorithm>
#include <iterator>
int main() {
   using namespace std;
   enum { N = 10 };
   int tab[N];
   generate(begin(tab), end(tab), generer);
   copy(begin(tab), end(tab), ostream_iterator<int>{ cout, " " });
   cout << endl;
   for_each(begin(tab), end(tab), remettre);
   generate(begin(tab), end(tab), generer);
   copy(begin(tab), end(tab), ostream_iterator<int>{ cout, " " });
   cout << endl;
}

Horizons dévoilés par cette technique

Nous avons, pour arriver à nos fins, examiné (et eu recours à) plusieurs techniques. Certaines sont expliquées dans d'autres articles et vous pouvez consulter les liens proposés ici et là sur la présente page si vous souhaitez en savoir plus.

Ce qui peut être considéré comme un peu plus novateur dans cette démarche (même si les idées en question ne peuvent être considérées de moi; ce sont des idées dans l'air du temps, que plusieurs gens oeuvrant sur des problèmes semblable ont eues à peu près autour des mêmes dates), va comme suit :

• L'héritage (privé en particulier) est une manière de remplacer la composition lorsque le besoin structurant est grand. On dit souvent (et à juste titre) que l'héritage privé est une manière d'exprimer des idées semblables à celles traditionnellement associées à la composition, mais il est possible, en ayant recours à l'héritage, d'exprimer aussi des relations conceptuelles entre classes génériques (comme le montre le truc Barton-Nackman). En combinant la détermination des parents par le code client et les listes de types, il est possible de déterminer une hiérarchie de classes à l'insu des classes elles-mêmes (Andrei Alexandrescu l'a montré dans le chapitre 2 de Modern C++ Design);
• La programmation générique permet la mise en place de classes d'enrobage ajoutant (ou garantissant) de la fonctionnalité à un autre type. Ce phénomène est à la base des mécaniques de pointeurs intelligents comme std::unique_ptr ou std::shared_ptr.
• Dans notre cas, la classe d'enrobage SingletonWrapper a quelques particularités intéressantes :
  • son rôle premier est d'exister sous un nom simple. Ceci permet à toute classe X de se dire amie de SingletonWrapper<X>, ce qui ne serait pas possible de manière générale si X devait être une structure complexe comme une liste de types. Il faut comprendre que tout type générique porte un nom qui dépend en partie du type générique et en partie des types auxquels il s'applique, ce qui fait que la simplicité de la généricité du patron SingletonWrapper, qui ne s'applique qu'à un type donné, le rend utilisable (pour mieux comprendre la nuance de cet argumentaire, essayez d'écrire ConteneurSingletons<T> en utilisant directement le type T comme attribut plutôt que SingletonWrapper<T>, et examinez le problème pour un singleton prospectif d'écrire sa qualification friend)
  • en étant amie de chaque classe X sur laquelle il s'applique, un SingletonWrapper peut encapsuler le type X pour y ajouter des fonctionnalités. C'est en ce sens que cette stratégie rejoint celle des pointeurs intelligents, qui enrobent les pointeurs simples et leur ajoutent des politiques de gestion de durée de vie et de partage
  • toute classe X désireuse de laisser un SingletonWrapper<X> la prendre en charge déclare SingletonWrapper<X> comme étant son amie. Il ne s'agit pas d'un bris d'encapsulation, le geste étant volontaire et posé à même l'interface de X, mais bien d'une injection volontaire de fonctionnalité à partir d'un tiers, donc une collaboration organique entre une entité concrète (la classe X) et une entité générique (SingletonWrapper<X>)
• La technique montrée dans SingletonDefinition.h et qui définit le nom singletons comme étant un ensemble organisé de singletons construits et détruits dans le respect de leurs dépendances mutuelles construit en fait un serveur $O(1)$ de singletons. Le code client accède à tout singleton du système par une même porte d'entrée (le type générique singletons) auquel l'invocation d'une méthode générique provoque une récursivité résolue à la compilation (donc $O(1)$ à l'exécution). Ceci rend le code d'accès aux singletons rapide, portable et robuste :
  • rapide parce que le code requis pour obtenir un singleton donné est toujours résolu à la compilation et est fortement optimisable (on devrait systématiquement obtenir une optimisation par Method Inlining devenant équivalente à un accès à une référence)
  • portable parce que le code client, incluant les singletons interdépendants, ne doit pas être modifié d'un projet à l'autre dans la mesure où les types des singletons impliqués ne change pas, et
  • robuste parce que toute erreur d'accès à un singleton deviendra une question de types et sera résolue à la compilation

De bons trucs pour la boîte à outils des programmeurs de code à haute performance, capables de vivre avec une solide dose d'abstraction.