Singleton ou variables statics """global""" ?

Bonjour à tous,

J'ai besoin de récupérer des valeurs dans un fichier texte et les attribuer à des variables.

Exemple : La touche "A" me permet d'ouvrir une fenêtre mais si je veux, je dois pouvoir changer dans le fichier texte cette touche par une autre.

Mon idée est la suivante : Je fais un seul fichier de conf, j'y accède en début de programme, je charge tout en mémoire, et quand j'en ai besoin, j'accède aux variables... (Car au final, le fichier en question contiendra bien plus que des raccourcis clavier...)

J'ai parcouru le net en long en large (et peut être de travers), pour voir les différentes solutions et je crois en avoir trouvé 3 :

1/ Utiliser les variables globales --> C'est pas propre, sources de conflits, donc à éviter fortement.
2/ Utiliser des variables statics
3/ Utiliser un singleton

Je vais donc creuser la reflexion sur la solution 2 ou 3, mais comment faire pour que mes variables statics, ou mon singleton, soient globales non pas à une classe, mais à l'ensemble de mes classes ?

Bonjour,

Citation:

---

Envoyé par base-un

comment faire pour que mes variables statics, ou mon singleton, soient globales non pas à une classe, mais à l'ensemble de mes classes ?

---

Je ne suis pas sûr de comprendre ton problème.
Les variables statiques sont certes définies dans une classe, mais ne nécessitent pas qu'elle soit instanciée pour être accessibles.
Si tu les déclares « publiques » (ou à défaut, leurs accesseurs), elles seront « globales » à tout ce qui connaît la classe à laquelle elles appartiennent.

Quant au « singleton », c'est un concept qui se modélise en C++ par une classe (avec des propriétés particulières).
Donc de la même manière…

Citation:

---

Envoyé par base-un

Je vais donc creuser la reflexion sur la solution 2 ou 3, mais comment faire pour que mes variables statics, ou mon singleton, soient globales non pas à une classe, mais à l'ensemble de mes classes ?

---

La déclarer en public static ne suffit-il pas?

Pattern monostate a la rescousse !

Pour simplifier, il s'agit d'un singleton caché. On y accède comme s'il s'agissait d'une classe tout ce qu'il y a de plus normale, qu'on instancie, etc, mais toutes les instances se réfère en fait à la même chose.

On peut d'ailleurs l'implémenter grâce à un singleton privé, si tu le souhaite vraiment :

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

class config { private: class config_info { private: config_info(const config_info&); config_info& operator=(const config_info&); config_info() { ... }; ~config_info() { ... } public: static config_info& instance() { static config_info infos; return infos; } public: void do_somehing(); };   config() { } ~config() { }   void do_something() { config_info::instance().do_something(); } };

---

Ce code n'a pas les faiblesses du pattern singleton (et en particulier : on peut changer l'implémentation de la classe plus tard, si nécessaire - par exemple si, finalement, le fichier config est utilisé par plusieurs applications en même temps. Alors la classe ne sera plus un monostate mais une classe normale, sans qu'on ait besoin de changer son interface).

Juste histoire de vérifier…
La classe config n'a pas accès aux membres privés ou protégés de la classe config::config_info, si ?

Citation:

---

Envoyé par Steph_ng8

Juste histoire de vérifier…
La classe config n'a pas accès aux membres privé ou protégés de la classe config::config_info, si ?

---

La partie privée d'une classe est privée à tout le monde :)

Déjà je vous remercie pour vos réponses. Je suis désolé si je suis un peu confus, mais je suis un noob en C++ et tout n'est pas encore très clair...

Donc, si je comprend bien, je vais créer ma class config avec le constructeur en privé (et pourquoi pas le destructeur) et un accesseur public...

Ensuite, j'ai plus qu'à acceder à mes méthodes pour charger les variables puis lire directement les variables publiques...

(Est ce que j'ai bon jusque là ???)

Ca donnerait quelque chose du style :

cfg.h

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

class cfg { public: static cfg* getCfg(void); bool loadRessourcesFromFile(string _str); // attribue une valeur depuis le fichier de conf à la variable _res; string _res;   private: cfg(){}; ~cfg(){};   static cfg* _singleton; };

---

main.cpp

Code:

---

1 2 3 4 5 6

main() { _cfg = cfg::getCfg(); _cfg->loadRessourcesFromFile("config.cfg"); }

---

Et donc si j'instancie ma classe cfg une nouvelle fois ailleurs, les instances se referont à la même chose ?
toto.h

Code:

---

1 2 3 4 5 6 7 8 9

#include "cfg.h"   class toto { public: toto(void); ~toto(void){}; };

---

toto.cpp

Code:

---

1 2 3 4 5 6 7 8 9 10

toto(void) { static cfg* _cfg = cfg::getCfg(); //Et maintenant j'accède à la valeur _res via _cfg->_res.c_str(); //Exemple : MessageBoxA(NULL, _cfg->_res.c_str(), "title", NULL);     }

---

Ca semble fonctionner, par contre, est ce une méthode propre et compréhensible ? Est ce que je vais dans mur avec cette facon de faire ?

Tu n'as pas besoin de mémoriser le pointeur de _cfg en global dans ta classe Toto, tu peux le récupérer à chaque fois: C'est la classe Cfg qui s'occupe de mémoriser, et aucune autre.

Citation:

---

Envoyé par Emmanuel Deloget

La partie privée d'une classe est privée à tout le monde :)

---

En fait j'avais mal lu ton code… :aie:

Mais ça me fait penser, la variable statique infos de la fonction config::config_info::instance() ne sera détruite qu'à la fin du programme.
Cette destruction est censée avoir lieu sous quel scope ?
Ça devrait être celui de la fonction précitée, mais elle sera déjà terminée… :?

Citation:

---

Envoyé par Steph_ng8

En fait j'avais mal lu ton code… :aie:

Mais ça me fait penser, la variable statique infos de la fonction config::config_info::instance() ne sera détruite qu'à la fin du programme.
Cette destruction est censée avoir lieu sous quel scope ?
Ça devrait être celui de la fonction précitée, mais elle sera déjà terminée… :?

---

La destruction des variables automatiques statique se fait dans l'ordre inverse de la sortie de leurs constructeurs.

C'est tordu, mais c'est comme ça :)

Ce que je voulais savoir, c'est d'où est censé être appelé son destructeur.
Depuis la fonction qui l'a créée (mais qui pourtant est terminée), ou alors depuis un scope global ?

Citation:

---

Envoyé par Steph_ng8

Ce que je voulais savoir, c'est d'où est censé être appelé son destructeur.
Depuis la fonction qui l'a créée (mais qui pourtant est terminée), ou alors depuis un scope global ?

---

Scope global : la variable statique est une variable globale non détruite, elle est donc récupérée une fois qu'on sort de la fonction main().

Donc si son destructeur est privé ou protégé, ça devrait poser problème, non ?

Citation:

---

Envoyé par Steph_ng8

Donc si son destructeur est privé ou protégé, ça devrait poser problème, non ?

---

Pas dans ce cas. Le destructeur n'est pas appelé explicitement dans le code, il est exécuté par le runtime.

Est-on sûr qu'il est appelé, tout court? Je ne me souviens plus du standard sur les destructions d'objets dynamiques en fin de processus...

Citation:

---

Envoyé par Médinoc

Est-on sûr qu'il est appelé, tout court? Je ne me souviens plus du standard sur les destructions d'objets dynamiques en fin de processus...

---

Dans mon code, ce n'est pas une création dynamique - c'est bien une variable statique - grouvernée par (références du dernier draft avant la publication de la norme en 98) 3.7.1 et 3.6.3§1, que je cite ici :

Citation:

---

Envoyé par Dernier Draft C++98, 3.6.3§1

Destructors for initialized objects of static storage duration (...) are called as a result of returning from main and as a result of calling exit. These objects are destroyed in the reverse order of the completion of their constructor or of the completion of their dynamic initialization.

---

L'initialisation dynamique (qui s'oppose à l'intialisation statique, mais qui n'a rien à voir avec la durée de vie dynamique) existe dès lors qu'un constructeur non trivial est exécuté pour créer un objet dont la durée de vie est statique.

Maintenant, si tu parles du code de base-un, la seule instance de cfg créée a une durée de vie dynamique. Une telle instance ne peut être détruite que par un appel explicite à son destructeur (via delete, ou directement - auquel cas la mémoire n'est pas libérée).

Ok.
Merci Emmanuel. :)