Mon Singleton est-il correct ?

Bonjour,

dans une appli A1, je dois mettre des infos en m�moire partag�e, qui seront utilis�es par une autre appli A2.
Donc pour �a j'ai fait une classe CSharedMemory. Pas de pb.

Dans cette appli A1, je sais donc que je dois utiliser un objet "global" CSharedMemory, et apr�s avoir utilis� "extern" que je trouvais un peu pourri, et en voyant l'exeple de la faq sur le Singleton, je me suis dit pourquoi pas l'utiliser.

Est-ce correct ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

class CGlobal {   private : CSharedMemory sm;   //Constructeur privé CGlobal() : sm(1000, "SM_TDELTA") { }   public : //Fonction static pour appeler notre seul objet CSharedMemory static CSharedMemory& GetSharedMemory(); };     CSharedMemory& CGlobal::GetSharedMemory() { static CGlobal glob; return glob.sm; }

---

Je compte utliiser cette classe CGlobal pour y mettre d'autres objets utilis�s encore auourd'hui en "extern"

Merci par avance.
@+

Il faut �galement que tu d�clares le constructeur de copie et l'op�rateur d'affectation en priv�, sinon il y aura possibilit� de dupliquer ton objet. Pas la peine de les d�finir par contre.

EDIT : j'avais aps fait attention, l� c'est ton CGlobal qui est un singleton, pas CSharedMemory.

Citation:

---

EDIT : j'avais aps fait attention, l� c'est ton CGlobal qui est un singleton, pas CSharedMemory.

---

Ben oui, c'est s�r que �a empeche personne de red�clarer un CSharedMemory,
mais ce que je voulais c'est + de propret� qu'un extern pour mes objets globaux ...

Citation:

---

Envoy� par olive_le_malin

Ben oui, c'est s�r que �a empeche personne de red�clarer un CSharedMemory,
mais ce que je voulais c'est + de propret� qu'un extern pour mes objets globaux ...

---

Ok pas de souci alors, c'est le commentaire de la m�thode GetCSharedMemory qui m'a induit en erreur :p

Par contre si tu veux g�rer plusieurs variables tu ne pourras plus d�clarer ton instance de CGlobal en static dans les fonctions. A moins de faire une fonction unique GetGlobals() qui renvoie l'instance unique de CGlobal, puis de faire des accesseurs classiques pour acc�der � ses diverses donn�es membres.

Attention aussi � la dur�e de vie de tes objets : avec une instance statique tu ne contr�les pas la destruction de ton singleton, et donc de ses donn�es membres.

Je plussoie aussi sur l'op�rateur = et le constructeur par copie priv�s non d�finis. Sinon ton singleton sera bancal.

La conception n'est pas claire. Dans ce cas, �a marchera parce qu'il n'y a qu'une seule fonction membre de CGlobal qui peut �tre utilis�e et que c'est dans cette fonction que le l'instance unique de CGlobal est cr��e. Mais que se passera-t-til s'il y en a deux ?

En fait, ta solution est � cheval entre deux mod�les de conception. Celui d'une classe 'singleton' et celui d'une classe non-instanciable qui ne regroupe que des variable 'statiques'.

Le premier mod�le correspond � ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

class CGlobal { public: // accès au singleton CGlobal& instance() { static CGlobal sf_instance; return sf_instance; }   Ressource1& ressource1() { return ressource1_; }   Ressource2& ressource2() { return ressource2_; }   protected: CGlobal() { /* init des variables membre */ }   private: Ressource1 ressource1_; Ressource2 ressource2_;   // Interdiction des copies CGlobal(const CGlobal& other); CGlobal& operator=(const CGlobal& other); }; ... /* Accès à une ressource */ CGlobal::instance().ressource1();

---

le second mod�le :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

class CGlobal { public: static Ressource1& ressource1() { static Ressource1 sf_ressource1; return ressource1; }   static Ressource2& ressource2() { static Ressource2 sf_ressource2; return ressource2; } private: CGlobal(); // Classe non instanciable };   // Accès à une ressource CGlobal()::ressource1();

---

M�ler les deux me semble bancal

Bonjour,
merci pour vos r�ponses.

Citation:

---

Il faut �galement que tu d�clares le constructeur de copie et l'op�rateur d'affectation en priv�, sinon il y aura possibilit� de dupliquer ton objet. Pas la peine de les d�finir par contre.

---

Citation:

---

Je plussoie aussi sur l'op�rateur = et le constructeur par copie priv�s non d�finis. Sinon ton singleton sera bancal.

---

OK, je vais le faire

Par contre, je comprends pas �a :

Citation:

---

Par contre si tu veux g�rer plusieurs variables tu ne pourras plus d�clarer ton instance de CGlobal en static dans les fonctions. A moins de faire une fonction unique GetGlobals() qui renvoie l'instance unique de CGlobal, puis de faire des accesseurs classiques pour acc�der � ses diverses donn�es membres.

---

Puisque l� je renvoie un accesseur � ma variable membre priv�e CSharedMemory, qu'est ce qui m'emp�che de le faire pour les autres ?

@+

Citation:

---

Envoy� par olive_le_malin

Par contre, je comprends pas �a :
Puisque l� je renvoie un accesseur � ma variable membre priv�e CSharedMemory, qu'est ce qui m'emp�che de le faire pour les autres ?

---

Singleton = une seule instance de la classe CGlobal.
Si je suis ton mod�le, avec 2 ressources cela donne �a

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

class CGlobal {   private : CSharedMemory sm; CRessource ressource;   //Constructeur privé CGlobal() : sm(1000, "SM_TDELTA"), ressource(...) { }   public : //Fonction static pour appeler notre seul objet CSharedMemory static CSharedMemory& GetSharedMemory();   //Fonction static pour appeler notre seul Ressource static CSharedMemory& GetRessource();   };     CSharedMemory& CGlobal::GetSharedMemory() { static CGlobal glob; // <--- Création d'une instance de CGlobal return glob.sm; }   CSharedMemory& CGlobal::GetRessource() { static CGlobal glob; // <--- Création d'une instance de CGlobal return glob.ressource; }

---

Ce qui pose beaucoup de soucis, puisque deux instance de CGlobal sont cr��es.
Cela implique que le constructeur de CGlobal sera appel� 2 fois, donc 2 instances de Ressource et CSharedMemory seront initialis�es.
Si ma deuxi�me ressource n�c�ssite des ressources uniques (socket sur une adresse IP par exemple), les cons�quences sont d�sastreuses.

Pauvre de moi, exact !!!
Merci ... ce fut tr�s clair !

Effectivement, sans l'�crire avec Plusieurs variables membres, je l'avais pas vu !

Je vais donc arranger �a comme il faut.

Par contre, Et il est vrai que ce que je veux faire correspond peut �tre mieux au second modele d�crit par Jan Rendeck.

Merci beaucoup :D

Re-bonjour,
une derni�re question :

par rapport au premier mod�le donn� par Jan Rendeck :
ne serait-il pas mieux d'�crire :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

class CGlobal { private : // acc�s au singleton static CGlobal& instance() { static CGlobal sf_instance; return sf_instance; } public: static Ressource1& ressource1() { return instance().ressource1_; } static Ressource2& ressource2() { return instance().ressource2_; } protected: CGlobal() { /* init des variables membre */ } private: Ressource1 ressource1_; Ressource2 ressource2_; // Interdiction des copies CGlobal(const CGlobal& other); CGlobal& operator=(const CGlobal& other); }; ... /* Acc�s � une ressource */ CGlobal::ressource1(); CGlobal::ressource2();

---

De ce fait on simplifie la notation � l'utilisation, non ?

@+

Ce n'est pas plus simple, AMA. Tu m�langes une fois encore les 2 m�thodes.
Si les m�thodes ressource1() et ressource2() sont 'static', quelle est l'utilit� de l'instance unique de la classe CGlobal ?
Dans ce cas, il faut mieux utiliser une classe non-instanciable pour regrouper l'ensemble de ces fonctions et variables comme je l'expose dans mon pr�c�dent message.

Citation:

---

Envoy� par Jan Rendek

Si les m�thodes ressource1() et ressource2() sont 'static', quelle est l'utilit� de l'instance unique de la classe CGlobal ?

---

Et ouais c'est vrai, il n'y en a pas ... :oops:

Merci