Do you Singleton ?

Oh yes, yes yes !! I do a lot !

Bref, bonjour, laissons de coter mon anglais aproximatif pour aujourd'hui ;)

Ce qui m'amène ici ets le Singleton, l'un des design pattern les plus utilsé à ce que j'ai compris . Et j'aimerai bien le comprendre !

J'ai lu pas mal d'article sur son rôle, son histoire, son implémentation etc ... Et je vais me baser sur la version de Loulou ( http://loulou.developpez.com/tutorie...eur3d/partie1/ ), qui à peu de choses près est l'une des formes les plus répandu d'implémention de Singleton .

< A partir de la, je vais raconter des choses ( sur ce que je crois avoir compris ) et poser des questions, vous pouvez ( devez?) me reprend sur chaque faute commise ( je tiens vraiment à comprendre tout les pincipes sous-jacents correctement ) >

Bref, le principe : on veux une classe mère de laquelle vont dériver nos classes basée sur le modèle singleton . On part sur un principe d'héritage car il parrait fastidieux de réimplémenter pour chauqe classe le même modèle.

Ensuite on templatise notre classe, puisqu'elle doit pouvoir créer et contenir un objet de type variable ( celui des classes dérivée de notre singleton ) .

La ou j'ai du mal c'est a la déclaration de ntore variable T, celle contenu dans le singleton ( celle du type de la classe dérivée, vous me suivez ? )

Code:

---

static T* Inst; // Instance de la classe

---

J'ai lu que le pointeur était la pour permettre de dérivé des classes, qu'est ce qui empecherais la dérivation avec une instance local et non un pointeur ?
[ c'est surement tout con comme réponse ]

Ensuite, j'ai du mal avec le "static", car en fait on ne cré de toute facons jamais une instance de la classe nous meme , je me trompe ?
On se résume a des CMonManager::GetInstance().mafonction(), donc on instancie jamais l'objet nous meme, donc la variable n'a pas besoin detre static , si ?

Passons, j'ai lu ceci

Citation:

---

A static variable inside a function is registered by at_exit(), and is deallocated when main exits. We have no control over when it gets called or when the destructors of global objects call the singleon - it may be already deallocated!

---

Ca pose problème ca non ? Comment résoudre ca?

De plus, la durée de vie de l'objet est lourde a géré non ? Il faut penser à faire le delete, sinon c'est pas gagné .... quelles sont les solutions à cela ? [ enfin si ca pose problème et que je ne suis pas à coté de la plaque hihi ]

Pour finir, voici la syntaxe de la déclaration de notre varaible statique, et j'ai du mal a la comprendre :

Citation:

---

template <class T> T* CSingleton<T>::Inst = NULL;

---

J'aurais mis ca moi

Citation:

---

T* CSingleton<T>::Inst = NULL;

---

ou ca plutot

Citation:

---

T* template <class T> CSingleton<T>::Inst = NULL;

---

Quel est le pourquoi du comment ?

Je pense en avoir finit avec mon flot de question, merci d'avance !

Salut,

en premier lieu , le principe du singleton n'est pas relié au template, tu peux tout a fais faire un Singleton sans template ca n'empeche rien.

Ensuite, il n'y a pas formcement d'heritage dans un Singleton, une seule classe qui n'herite de personne et dont personne n'herite peut etre un Singleton.

Par contre le static est important, c'est lui qui va assurer que tu as une seule instance de cette classe. C'est pour cette raison que l'on n'instancie jamais soit meme un Singleton avec new, on utilise une methode static de la class generalement nommé GetInstance (mais bon le nom c'est au choix).

Quand tu fais GetInstance tu vas initialiser ton objet si il n'existait pas avant et simplement donner celui qui existe si il existait deja.

Pour la destruction il faut souvent passer par une autre fonction dans le genre MonSingleton::Destroy().

en tout cas il ne faut pas oublier le static sinon tu risque dA'voir des problemes avec ton singleton.

Et enfin, je suppose qu'il y a plein d'autres facon de voir et d'utiliser un Singleton. Personnellement dans la compagnie pour laquelle je travail on utilise par exemple un Singleton pour gerer la memoire utiliser par nos images (un MemoryManager) comme c'est un Singleton je peux toujours appeler MemoryManager::GetInstance() pour recuperer mon instance et je sais que c'est mon UNIQUE MemoryManager de l'application. et ensuite je peux lui demander l'Etat de ma memoire :

Code:

---

1 2 3

MemoryManager* MonMemoryManager = MemoryManager::GetInstance(); int64 MemoryUsed = MonMemoryManager->GetMemUsed();

---

Citation:

---

en premier lieu , le principe du singleton n'est pas relié au template, tu peux tout a fais faire un Singleton sans template ca n'empeche rien.

Ensuite, il n'y a pas formcement d'heritage dans un Singleton, une seule classe qui n'herite de personne et dont personne n'herite peut etre un Singleton.

---

Je me suis mal exprimé, car ca je suis parfaitement d'accord ^^

Citation:

---

Quand tu fais GetInstance tu vas initialiser ton objet si il n'existait pas avant et simplement donner celui qui existe si il existait deja.

---

ex :

Code:

---

1 2 3

CManager * pt = CManager()::GetInstance() CManager * pt2 = CManager()::GetInstance()

---

Hummm on va donc avoir si ma varaible n'est pas static , les deux pointeurs pointent sur deux objets différents, c'est ca ? En réalité il n'exitse AUCUNE instance de CSingleton ( la version templatisé ), c'est juste un genre d'interface offrant des fonction accessible sasn instanciation ( donc statique )
Je me rapproche ?

Citation:

---

Pour la destruction il faut souvent passer par une autre fonction dans le genre MonSingleton::Destroy().

---

SI j'ai bien comprit le passage en anglais que j'ai quote, ca pose problème de passer par une fonction destroy,non ?

Beaucoup de gens utilisent le singleton pour le défi technique rigolo qu'il rempli. A savoir : empécher la création de plus d'un objet d'un type donné.

Personnellement, je suis aujourd'hui plus pragmatique. Un singleton n'est qu'une variable globale déguisée à l'aide d'un nom rigolo : "singleton".

Ignorer ce que c'est véritablement est le meilleur moyen d'avoir un design qui abuse de ces choses. Et franchement, c'est pas tip-top après.
Et encore moins tip-top quand on voit des singletons qui s'héritent et qui ... étrangement partagent les données communes sensées être uniques ... en les dupliquant en autant d'exemplaires que de classes filles.

Bref, pour moi c'est une facilité qui permet d'accéder "rapidement" à une variable globale dont on arrive à peu près à maitriser la durée de vie. Dans les autres facilités, il y a une protection contre les accès concurrents qui est pseudo efficace (même l'idiome du double-lock ne fonctionne pas correctement). Je pense aujourd'hui qu'il vaut mieux un T::create(arguments) qui est appelé une seule fois au démarrage de l'application, dans un thread qui est alors unique. Et un T::instance() qui renvoit l'instance sans la construire.

Modern C++ Design d'Andrei Alexandrescu a un très bon chapitre sur les singletons : il en fait le tour.
A noter que dans sa solution, que l'on retrouve évidemment dans Loki, une classe est définie sans se préoccuper d'un quelconque apsect singleton. Et qu'ensuite il utilise une classe générique qui à partir d'un type "normal" définit un type singleton dont il ne peut exister qu'une seule instance à un moment donné. C'est un peu la même chose dans ACE.

Assez d'accord. J'ajouterais qu'à mon sens, son plus gros intérêt en terme de gestion de durée de vie, c'est surtout la gestion d'ordre d'initialisation entre deux singletons.

Tout à fait. Et chez les singletons les plus évolués, les dépendances au moment de la destruction sont aussi prises en compte.