Lire un fichier .reg + pb singleton

Bonjour,

J'ai un problème en C++ où je débute. Je suis en période d'essai avec un chef vraiment pas commode ... et je dois réaliser ceci :

Créer une classe « c_usn_file_registry » qui fournit les 4 méthodes suivantes :

Code:

---

static bool c_usn_file_registry::instancier_singleton(nmutility::CString nom_fichier)

---

Elle crée un singleton « usn_file_registry », lit le fichier .reg (fichier base de registres) donné en argument, et construit une structure de données interne (basée sur « nmutility::CStdMap ») avec l'ensemble des valeurs contenues dans le fichier.

Code:

---

static c_usn_file_registry* c_usn_file_registry::get_singleton();

---

Elle retourne le singleton créé par instancier_singleton.

Code:

---

int c_usn_file_registry::lire_entier(nmutility::CString nom_chemin, nmutility::CString nom_valeur)

---

et

Code:

---

nmutility::CString c_usn_file_registry::lire_chaine(nmutility::CString nom_chemin, nmutility::CString nom_valeur)

---

Ces 2 méthodes retournent l'entier ou la chaîne correspondant à la clé demandée (identifiée par son chemin et son nom).

Un des mes gros problèmes est que je ne sais pas trop ce qu'est un singleton et donc ce que doivent faire get_singleton et instancier_singleton.

De plus, il n'y aurait pas une bibliothèque qui saurait faire ça, c'est à dire lire des valeurs dans une fichier .reg ?

Si quelqu'un pouvait m'aider, son aide serait vraiment la bienvenue ...

Merci.

Tapiou.

Bonjour,

En mathématiques, un singleton est un ensemble qui contient un et un seul élément. Exemple : { 0 }. Par extension, en programmation orientée objet, on a appelé « singleton » une classe qui est faite pour n'être instanciée qu'une seule fois (ou, à la limite, un nombre fixe et limité) et qui se réfère ensuite toujours à la même instance.

http://fr.wikipedia.org/wiki/Singlet..._conception%29

C'est une approche parfois séduisante mais qui a été décriée par certains.

Merci pour le lien, j'ai la théorie maintenant mais concrètement ?
Je patauge encore ...:(

Tapiou.

Pour coder un singleton, il y a plusieurs écoles, mais toutes partent d'une variable globale qui contiendra l'instance unique du singleton, et d'une méthode globale pour la récupérer.

Code:

---

1 2 3 4 5 6 7 8 9

class RegReader { static RegReader* instance; public: static RegReader* getInstance() { return instance; } };   //dans le cpp RegReader* RegReader::instance = 0;

---

Ca te donne déja l'accès global. Reste ensuite a voir comment tu veux créer ton singleton. Deux options simples :
Créer une méthode create

Code:

---

1 2 3 4 5

static RegReader* create() { if(!instance) instance = new RegReader; return instance; }

---

ou alors réécrire getInstance de cette facon afin que getInstance créé l'instance si ce n'est pas fait :

Code:

---

1 2 3 4 5

static RegReader* getInstance() { if(!instance) instance=new RegReader; return instance; }

---

Dans tous les cas, il faut coupler ca avec une méthode destroy a appeller quand tu n'as plus besoin du singleton

Code:

---

1 2 3 4 5

static void destroyInstance() { if(instance) delete instance; instance=0; }

---

Dans tous les cas, constructeur et destructeur privé afin de prévenir une création ou une destruction autrement que par les méthodes fournies

Merci Rewpparo !

Tes explications vont bien m'aider :lol:

Mais bon j'ai encore du travail pour résoudre l'ensemble du problème, vu que je débute en C++ et que j'avance comme une tortue.

Donc s'il y a une bonne âme qui a des suggestions à me faire, surtout qu'elle n'hésite pas ! ;)

Tapiou.

Un truc :

Citation:

---

Envoyé par tapiou

De plus, il n'y aurait pas une bibliothèque qui saurait faire ça, c'est à dire lire des valeurs dans une fichier .reg ?

---

je pense qu'il te faudra le parser à la main. Utilises fstream pour faire ca.

Merci pour l'info, je vais regarder.

Tapiou.

Salut,

Citation:

---

Envoyé par Rewpparo

Pour coder un singleton, il y a plusieurs écoles, mais toutes partent d'une variable globale qui contiendra l'instance unique du singleton, et d'une méthode globale pour la récupérer.

Code:

---

1 2 3 4 5 6 7 8 9

class RegReader { static RegReader* instance; public: static RegReader* getInstance() { return instance; } };   //dans le cpp RegReader* RegReader::instance = 0;

---

Ca te donne déja l'accès global. Reste ensuite a voir comment tu veux créer ton singleton. Deux options simples :
Créer une méthode create

Code:

---

1 2 3 4 5

static RegReader* create() { if(!instance) instance = new RegReader; return instance; }

---

ou alors réécrire getInstance de cette facon afin que getInstance créé l'instance si ce n'est pas fait :

Code:

---

1 2 3 4 5

static RegReader* getInstance() { if(!instance) instance=new RegReader; return instance; }

---

Dans tous les cas, il faut coupler ca avec une méthode destroy a appeller quand tu n'as plus besoin du singleton

Code:

---

1 2 3 4 5

static void destroyInstance() { if(instance) delete instance; instance=0; }

---

Dans tous les cas, constructeur et destructeur privé afin de prévenir une création ou une destruction autrement que par les méthodes fournies

---

Une autre solution consiste à utiliser une variable statique directement dans getInstance:

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 Reader { public: static Reader & getInstance() { static Reader r; return r; } /* !!!C++11 ony !!!   * interdire la copie et l'affectation (il faut d'ailleurs veiller à le faire   * aussi dans la version de Rewpparo ;) )   */ Reader(Reader const &) = delete; Reader & operator = ( Reader const &) = delete;   /* les fonctions qui vont bien */ private: /* avant C++11 :   * interdire la copie et l'affectation   */ Reader(Reader const &); // déclaré, non implémenté (pour éviter // que le compilateur ne fournisse la version publique) Reader & operator= (Reader const &); // déclaré, non implémenté (pour éviter // que le compilateur ne fournisse la version publique) Reader(); // à implémenter ;) ~Reader(); // à implémenter ;) }

---

Cela permet d'éviter le recours à un pointeur, et donc de garder une syntaxe objet ;)

Ceci dit
On ne le répétera jamais assez, mais les singletons et les variables statiques, c'est mal!!!

La raison principale est qu'une variable statique n'est finalement qu'une variable globale qui se cache bien, mais elle présente exactement les mêmes problèmes en termes de réentrance et de pureté des fonctions!!!

Le tout, sans oublier que, du fait de sa disponibilité dans l'ensemble du code, l'utilisateur peut etre tenté d'accéder à cette variable globale (ou à ce singleton) depuis des endroits de code auxquels il ne devrait pas pouvoir y accéder, avec tous les risques que cela comporte en terme de dépendances ou de références circulaires!!!

Et si tu le souhaites, on peut aussi parler des problèmes relatifs à la gestion de threads et des mécanismes nécessaires pour arriver à gérer le singleton de manière thread safe ;)

Le meilleur moyen de garantir qu'il n'y aura jamais qu'une et une seule instance d'un type donné est encore de déclarer cette variable dans une partie du code que l'on sait n'être utilisée qu'une seule fois (par exemple, au niveau de la classe principale de l'application ;)) et de veiller à ne transmettre cette variable (sous forme de référence, éventuellement constante) qu'aux fonctions qui en ont impérativement besoin ;)

Je me suis récemment retrouvé face à un code où il n'y avait pas un singleton, mais carrément plusieurs, avec un singleton qui regroupait, ou peu s'en faut, l'ensemble des fonctionnalités des autres...

Le problème, quand j'ai voulu apporter une modification due à l'évolution du business, c'est que je me suis aperçu que les singleton "secondaires" (ou du moins celui sur lequel je devais travailler) faisaient régulièrement appel à ce singleton "général" :aie:

Je ne te raconte pas les soucis que cela m'a occasionné pour arriver à faire ce que l'on m'avait demandé :aie:

Citation:

---

Envoyé par koala01

Je me suis récemment retrouvé face à un code où il n'y avait pas un singleton, mais carrément plusieurs, avec un singleton qui regroupait, ou peu s'en faut, l'ensemble des fonctionnalités des autres...

Le problème, quand j'ai voulu apporter une modification due à l'évolution du business, c'est que je me suis aperçu que les singleton "secondaires" (ou du moins celui sur lequel je devais travailler) faisaient régulièrement appel à ce singleton "général" :aie:

Je ne te raconte pas les soucis que cela m'a occasionné pour arriver à faire ce que l'on m'avait demandé :aie:

---

Arrivé à ce point, je pense qu'on peut légitimement se demander en quoi ça reste de la programmation objet. :-) De bonnes vieilles fonctions impératives auraient largement rempli leur mission.

Citation:

---

Envoyé par koala01

Code:

---

1 2 3 4 5 6

static Reader & getInstance() { static Reader r; return r; }

---

---

Je ne comprend pas la syntaxe, pour moi une static c'est dans une classe. La ca fait un peu variable locale static (oxymore). C'est comme déclarer une variable static, mais qu'on ne peut utiliser que dans la méthode ?
Ca demande quand même une définition dans le cpp ?

Citation:

---

Envoyé par koala01

Code:

---

1 2 3 4 5

/* !!!C++11 ony !!!   * interdire la copie et l'affectation (il faut d'ailleurs veiller à le faire   * aussi dans la version de Rewpparo ;) )   */

---

---

Citation:

---

Envoyé par Rewpparo

Dans tous les cas, constructeur et destructeur privé afin de prévenir une création ou une destruction autrement que par les méthodes fournies

---

J'aurais du le mettre plus en avant, car c'est vrai que c'est une partie intégrante du pattern.

Citation:

---

Ceci dit
On ne le répétera jamais assez, mais les singletons et les variables statiques, c'est mal!!!

---

+1, mais en l'occurence c'est son patron pas commode qui a imposé le pattern. Et pour espèce de base de registre, je trouve que c'est le seul cas où ca se justifie. Le seul singleton de mon projet est quelque chose du style.

Et j'ajouterais sur les variables globales que pour moi les seules acceptables sont privées, et en pensant bien l'interface.

Citation:

---

Envoyé par Obsidian

Arrivé à ce point, je pense qu'on peut légitimement se demander en quoi ça reste de la programmation objet. :-) De bonnes vieilles fonctions impératives auraient largement rempli leur mission.

---

Oui, je sais...

Mais bon, je te rassure, je ne suis pas du tout responsable de cet imbroglio, je n'ai fait que le subir ;)

Citation:

---

Envoyé par Rewpparo

Je ne comprend pas la syntaxe, pour moi une static c'est dans une classe. La ca fait un peu variable locale static (oxymore). C'est comme déclarer une variable static, mais qu'on ne peut utiliser que dans la méthode ?
Ca demande quand même une définition dans le cpp ?

---

Non, pas du tout...

On profite du fait que la fonction continue d'exister (du fait de sa déclaration comme static) en dehors de la fonction, et qu'elle n'est pas recréée à chaque fois que la fonction est appelée, tout simplement ;)

La raison qui fait qu'une variable membre statique doit etre définie dans le *.cpp est, tout simplement, due au fait qu'elle doit être construite avant le premier appel au constructeur de la classe dans laquelle elle se trouve, étant donné qu'une variable statique est totalement indépendante de toute instance de la classe.

Dans le cadre d'une variable de fonction, il en va tout autrement : elle peut parfaitement n'être créée qu'au premier appel de la fonction (qui, elle doit, pour le pattern singleton du moins, etre statique pour ne pas dépendre d'une instance de la classe) vu qu'elle ne sera de toutes manières pas utilisée... avant le premier appel à la fonction ;)

Citation:

---

J'aurais du le mettre plus en avant, car c'est vrai que c'est une partie intégrante du pattern.

---

C'est pour cela que je l'ai mis en évidence, en indiquant les deux solutions ;)

Mais je ne doute absolument pas que l'oubli n'est du qu'à une distraction passagère ou à une quelconque activité t'ayant incité à terminer ta réponse au plus vite ;)

Citation:

---

+1, mais en l'occurence c'est son patron pas commode qui a imposé le pattern.

---

Je sais bien, mais bon, ce n'est pas une raison pour ne pas faire le rappel, et, qui sait, inciter tapiou à dire à son patron que "CEYMAL" :D

Citation:

---

Et pour espèce de base de registre, je trouve que c'est le seul cas où ca se justifie. Le seul singleton de mon projet est quelque chose du style.

---

Je dirais plutot : justement !!! la base de registre, est, typiquement, lue une fois à l'initialisation de l'application et, éventuellement, lue à la sortie de celle-ci...

Et une grosse partie des informations qu'elle contient n'ont, en définitive, qu'une portée très limitée dans le temps (ex : la vérification de la license qui ne sera typiquement utilisée qu'au lancement de l'application)...

Il me semble dommage de se trimbaler l'ensemble des informations chaque fois que l'on souhaite savoir si le texte doit etre écrit en vert fluo ou en brun caca doigt :aie: et, surtout, de se trimbaler en plus tout le système de lecture et d'écriture que cela sous tend ;)

Car, plus ces informations vont voyager au travers de l'application, plus on est susceptible d'aller y chipoter, de manière autorisée ou non ;)

N'hésitons pas à créer une classe Reader et une classe Writer, mais utilisons les intelligemment : Reader dans le constructeur pour aller chercher les infos (et les placer aux endroits qui vont bien) et Writer dans le destructeur pour aller chercher les infos où elles se trouvent et les réécrire dans la base de registre ;)

Citation:

---

Et j'ajouterais sur les variables globales que pour moi les seules acceptables sont privées, et en pensant bien l'interface.

---

... ou constantes, si elles sont publique ;)

Citation:

---

Envoyé par koala01

Non, pas du tout...

On profite du fait que la fonction continue d'exister (du fait de sa déclaration comme static) en dehors de la fonction, et qu'elle n'est pas recréée à chaque fois que la fonction est appelée, tout simplement ;)

La raison qui fait qu'une variable membre statique doit etre définie dans le *.cpp est, tout simplement, due au fait qu'elle doit être construite avant le premier appel au constructeur de la classe dans laquelle elle se trouve, étant donné qu'une variable statique est totalement indépendante de toute instance de la classe.

Dans le cadre d'une variable de fonction, il en va tout autrement : elle peut parfaitement n'être créée qu'au premier appel de la fonction (qui, elle doit, pour le pattern singleton du moins, etre statique pour ne pas dépendre d'une instance de la classe) vu qu'elle ne sera de toutes manières pas utilisée... avant le premier appel à la fonction ;)
C'est pour cela que je l'ai mis en évidence, en indiquant les deux solutions ;)

---

C'est intéressant, je connaissais pas. Comment ca marche si le singleton est défini dans des libs ? J'ai eu des problèmes il y a longtemps avec des variables static qui n'étaient pas synchrones entre une lib et le programme principal, problèmes que d'ailleurs je n'avais pas vraiment compris et qui m'ont amené à considérer avec encore plus de méfiance toute variable static, surtout les singletons. Ça change quelque chose d'utiliser static comme ca ?

Citation:

---

Envoyé par koala01

Je dirais plutot : justement !!! la base de registre, est, typiquement, lue une fois à l'initialisation de l'application et, éventuellement, lue à la sortie de celle-ci...

Et une grosse partie des informations qu'elle contient n'ont, en définitive, qu'une portée très limitée dans le temps (ex : la vérification de la license qui ne sera typiquement utilisée qu'au lancement de l'application)...

Il me semble dommage de se trimbaler l'ensemble des informations chaque fois que l'on souhaite savoir si le texte doit etre écrit en vert fluo ou en brun caca doigt :aie: et, surtout, de se trimbaler en plus tout le système de lecture et d'écriture que cela sous tend ;)

Car, plus ces informations vont voyager au travers de l'application, plus on est susceptible d'aller y chipoter, de manière autorisée ou non ;)

---

En l'occurrence, je me sert de ca pour un jeu vidéo, pour enregistrer les paramètres comme les paramètres de la fenêtre, les touches, etc.. Le singleton centralise les infos de plusieurs sources (argc argv, fichier de conf, IHM de config) et les met à disposition de ceux qui en ont besoin.

Les touches par exemple, j'ai besoin d'en savoir la configuration a chaque fois que je lance une partie pour recréer les binds, ou si le joueur monte dans un véhicule et change de manière de contrôler le jeu.

La fenêtre, j'en ai besoin que quand ca change, mais ca peut changer à n'importe quel moment, y compris pendant la partie.

J'ai donc besoin des infos un peu tout le temps. Je pourrais me contenter de faire une classe qui facilite l'accès au fichier de conf, mais je ne ferais que déplacer le problème, et ca ne me permettrais pas de mixer facilement le fichier de conf et les arguments de ligne de commande.

Citation:

---

Envoyé par Rewpparo

En l'occurrence, je me sert de ca pour un jeu vidéo, pour enregistrer les paramètres comme les paramètres de la fenêtre, les touches, etc.. Le singleton centralise les infos de plusieurs sources (argc argv, fichier de conf, IHM de config) et les met à disposition de ceux qui en ont besoin.

Les touches par exemple, j'ai besoin d'en savoir la configuration a chaque fois que je lance une partie pour recréer les binds, ou si le joueur monte dans un véhicule et change de manière de contrôler le jeu.

La fenêtre, j'en ai besoin que quand ca change, mais ca peut changer à n'importe quel moment, y compris pendant la partie.

J'ai donc besoin des infos un peu tout le temps. Je pourrais me contenter de faire une classe qui facilite l'accès au fichier de conf, mais je ne ferais que déplacer le problème, et ca ne me permettrais pas de mixer facilement le fichier de conf et les arguments de ligne de commande.

---

Tu as besoin de tout pendant toute la durée de ton application, mais tu n'as (ou, du moins, tu devrais n'avoir) besoin d'informations particulières que sur des portions de code bien définies...

Pour reprendre tes exemples :

Tu vas, effectivement, avoir besoin de la lire la configuration des touches au chargement, mais elles ne seront manipulées finalement qu'à deux endroits : dans le gestionnaire d'événement pour déterminer quelle action est entreprise sur l'appui de quelle touche et, éventuellement, au niveau du panneau de configuration, qui devra de toutes manière disposer du système d'événement pour y faire les mises à jour.

Il n'y a que le gestionnaire graphique (et encore une fois, le panneau de configuration) qui ait réellement besoin des informations de fenêtre, meme si elles sont lues en début de partie, et, encore une fois, le panneau de configuration devra, de toutes manières, s'adresser au gestionnaire graphique pour lui faire prendre les nouveaux réglages en comptes.

On peut continuer comme cela pour tout ce qu'on peut imaginer : les informations relatives au niveau de difficulté n'intéressent que le moteur de jeu et l'intelligence artificielle (et, décidément, toujours le panneau de configuration ;)), la gestion des sauvegarde de données n'intéresse éventuellement que la partie propre à la gestion de l'inventaire et à la gestion de la position dans le jeu dans le moteur de jeu, et ainsi de suite ;)

Par contre, tu n'en auras rien à foutre d'avoir la taille de la fenêtre au niveau du moteur d'intelligence artificielle ou quand il s'agira d'évaluer le niveau de difficulté du jeu ;)

Etant entendu que tu n'auras de toute manière qu'un moteur de jeu, un moteur graphique, un gestionnaire d'événement etc , pourquoi ne pas faire en sorte que les informations qui les intéressent se trouvent dans ces différents modules (quitte à créer une classe dont la responsabilité serait à chaque fois de maintenir les informations à jour ;) ) :question:

Tu auras, bien sur, des dépendances entre ces différents modules, car certains d'entre eux devront, de toutes manières, transmettre des informations à d'autres, mais le fait de "dispatcher" les informations au niveau du "module" t'éviterait d'avoir des dépendances partant "dans tous les sens" 'uniquement" parce que tu as été "assez bête" que pour regrouper les informations propres au moteur de rendu et celles propres à la gestion de la difficulté au sein d'une classe qui chapeaute le tout, mais qui a, en retour, une dépendance forte envers tout ;)

Le tout, sans oublier le fait que, en mettant au point une stratégie de séparation de l'information assez fine, tu gardera un bien meilleur contrôle sur le "qui fait quoi" avec ces données, t'évitant ainsi que l'appuis malencontreux sur une touche ne te fasse passe en 800/600 alors que ton pc est configuré en 1920 par dieu sait combien (et autres joyeusetés du genre, évidemment :D) ;)

Après, il reste bien sur le cas particulier du panneau de configuration qui doit avoir accès à la quasi totalité des endroits où les informations sont maintenues...

Mais, comme il doit, de toutes manières, avoir accès à ces différents modules pour leur indiquer (le cas échéant) qu'une partie de la configuration a changé et qu'ils doivent en tenir compte, même quand toutes les infos sont regroupées au niveau d'un singleton, il n'y a, a priori pas d'inquiétudes à avoir ;)

Citation:

---

Envoyé par koala01

Etant entendu que tu n'auras de toute manière qu'un moteur de jeu, un moteur graphique, un gestionnaire d'événement etc , pourquoi ne pas faire en sorte que les informations qui les intéressent se trouvent dans ces différents modules (quitte à créer une classe dont la responsabilité serait à chaque fois de maintenir les informations à jour ;) ) :question:

---

Parce que ces informations ont des points de centralisation forts : les paramètres de la ligne de commande et le fichier de configuration. Je pourrais les dispatcher entre les différents modules au démarrage, et les collecter quand il s'agit d'enregistrer le fichier de conf. Mais il faudra que je revoie le code de collecte/dispatch à chaque fois que j'ajoute un nouveau paramètre pour l'envoyer au bon endroit ou le récupérer au bon endroit. La chaque système récupère les paramètres dont il a besoin, s'il n'est pas présent il définit lui même la valeur qu'il veut, et elle sera enregistrée pour la fois suivante.

Citation:

---

Envoyé par koala01

Après, il reste bien sur le cas particulier du panneau de configuration qui doit avoir accès à la quasi totalité des endroits où les informations sont maintenues...

Mais, comme il doit, de toutes manières, avoir accès à ces différents modules pour leur indiquer (le cas échéant) qu'une partie de la configuration a changé et qu'ils doivent en tenir compte, même quand toutes les infos sont regroupées au niveau d'un singleton, il n'y a, a priori pas d'inquiétudes à avoir ;)

---

Justement, chez moi le panneau de configuration ne fait que signifier les nouveaux paramètres au singleton, qui lui va envoyer des events aux différents systèmes pour leur signifier les changements. Ça évite que le panneau de configuration ne touche à tout justement, car là aussi tu as une dépendance forte, et à un endroit beaucoup plus sensible. Certes mon singleton est une dépendance forte, mais au moins lui je suis sur qu'il ne dépend de personne, donc pas de dépendances cycliques ou autres.
C'est même principalement pour résoudre cette dépendance que je me suis résolu a utiliser un singleton.

Citation:

---

Envoyé par koala01

Le tout, sans oublier le fait que, en mettant au point une stratégie de séparation de l'information assez fine, tu gardera un bien meilleur contrôle sur le "qui fait quoi" avec ces données, t'évitant ainsi que l'appuis malencontreux sur une touche ne te fasse passe en 800/600 alors que ton pc est configuré en 1920 par dieu sait combien (et autres joyeusetés du genre, évidemment )

---

C'est en effet la seule faiblesse de mon système, le manque de gestion de permissions. Mais c'est simple a débugger, il suffit de regarder le fichier de conf pour voir le paramètre qui merde, et chercher le bout de code qui touche à cette clé. Les conventions d'écriture dans les clés permettent de limiter le risque d'erreur en séparant bien tout en sections (video, IA, physique..). Je pourrais même créer des interfaces qui limitent la capacité d'édition à telle ou telle section si je rencontre des problèmes.

Citation:

---

Envoyé par Rewpparo

Parce que ces informations ont des points de centralisation forts : les paramètres de la ligne de commande et le fichier de configuration. Je pourrais les dispatcher entre les différents modules au démarrage, et les collecter quand il s'agit d'enregistrer le fichier de conf. Mais il faudra que je revoie le code de collecte/dispatch à chaque fois que j'ajoute un nouveau paramètre pour l'envoyer au bon endroit ou le récupérer au bon endroit.

---

Je présumes que tu as déjà pris soin d'enregistrer ta conf "par lot", dans le sens ou ta fonction write (ou read, selon le sens de travail ;) ) ressemble sans doute à

Code:

---

1 2 3 4 5 6 7

void singleton::write() { saveWindowConfig(); saveKeyConfig(); saveDifficultyConfig(); /* ...*/ }

---

chaque fonction se chargeant de sauvegarder (ou de lire, en core une fois) le lot d'informations qui l'intéresse, chaque fonction appelant d'autres fonctions traitant des lots plus particuliers ...

J'espère en tout cas que tu n'a pas tapé tes options de configuration "au petit bonheur la chance" en fonction de tes besoins, car tu finira par avoir vraiment énormément de mal à t'y retrouver ;)

Si tel est effectivement le cas, un simple "Reader" en début d'application et un Writer en fin d'application permettent (qui peuvent d'ailleurs etre regroupés en "Serializer, avec les fonctions read et write ;) ), suffisent très amplement à envoyer les lots d'informations vers "qui de droit" et à les récupérer, en ne devant au pire rajouter qu'une instruction chaque fois que tu rajoutes une option de configuration ;)

Citation:

---

La chaque système récupère les paramètres dont il a besoin, s'il n'est pas présent il définit lui même la valeur qu'il veut, et elle sera enregistrée pour la fois suivante.

---

Qu'est ce qui t'empêche de faire que ce comportement ait lieu au niveau du module, juste après réception des lots d'information :question:

Le problème que j'exposais la tantot pour indiquer qu'il fallait vraiment éviter les singletons, il est survenu pour une raison bien simple : le singleton général avait été nommé "PropertyManager"...

Un nom bateau s'il en est qui permet de regrouper tout ce qui ressemble de près ou de loin à une propriété (et dieu sait, s'il existe, que l'on peut trouver des propriétés partout ;))

Au fil des cinq ans de développement, c'est devenu une espèce de monstre polymorphe dont on s'étonnerait presque qu'il ne fasse pas le café :D

(Il faut dire, pour etre précis, qu'il enregistre en plus ses données dans trois fichiers totalement différents :aie:)

Cela fait maintenant un an que l'on se rend effectivement compte que ce truc devient impossible à gérer sous cette forme et que l'on essaye de dispatcher les différentes responsabilités dans différents gestionnaires plus spécialisés, le tout (c'est quand meme préférable pour une application qui est en prod ;)) en évitant de tout casser...

(Et, pour faire taire les mauvaises langues, c'est à peu près lors de mon arrivée sur le projet que l'on a décidé de lancer de "refactoring" progressif, meme si je n'en suis pas l'instigateur, je ne suis pas responsable de la dérive ;))

Si je te raconte cela, c'est pour te dire qu'il s'agit d'une expérience vécue, et d'une situation que je subis encore au jour le jour, et non d'un simple exercice de style de "belle programmation" ;).

Ce que j'essaye de t'expliquer c'est que, que tu travailles en solo pour ton propre plaisir ou en équipe à titre professionnel, la seule présence du singleton pour gérer la configuration, surtout s'il est nommé PropertyManager ou ConfigManager t'ouvre une voie royale et t'emmène déjà dessus pour en arriver à un mastodonte effrayant dont tout le monde dit qu'il faut revoir la technique mais dont personne n'ose vraiment s'y coller, de peur de "tout casser"...

Si tu as encore l'occasion de revenir en arrière et de couper la tête à hydre avant qu'elle ne devienne monstrueuse, crois moi, il est surement plus que temps de t'y atteler, car si tu décides de t'y mettre quand tu te rendras effectivement compte que cela devient ingérable, tu vas très certainement t'y casser les dents ;)

Citation:

---

Justement, chez moi le panneau de configuration ne fait que signifier les nouveaux paramètres au singleton, qui lui va envoyer des events aux différents systèmes pour leur signifier les changements. Ça évite que le panneau de configuration ne touche à tout justement, car là aussi tu as une dépendance forte, et à un endroit beaucoup plus sensible. Certes mon singleton est une dépendance forte, mais au moins lui je suis sur qu'il ne dépend de personne, donc pas de dépendances cycliques ou autres.
C'est même principalement pour résoudre cette dépendance que je me suis résolu a utiliser un singleton.

---

Le gros problème, c'est que le singleton devient le "point de rencontre" de tous tes modules, et que chaque module dépend explicitement de ton singleton, en plus de toutes les dépendances plus "logiques"...

Il suffit donc que tu rajoutes une fonction pour gérer un nouvel aspect de ta fenêtre pour que tu te trouves face à l'obligation de recompiler l'ensemble des modules (que ce soit en tout ou en partie) alors que tu aurais très bien pu n'avoir à recompiler que le module graphique (pour suivre mon exemple ;)), et encore... meme pas forcément l'ensemble du module graphique ;)

Citation:

---

C'est en effet la seule faiblesse de mon système, le manque de gestion de permissions. Mais c'est simple a débugger, il suffit de regarder le fichier de conf pour voir le paramètre qui merde, et chercher le bout de code qui touche à cette clé. Les conventions d'écriture dans les clés permettent de limiter le risque d'erreur en séparant bien tout en sections (video, IA, physique..). Je pourrais même créer des interfaces qui limitent la capacité d'édition à telle ou telle section si je rencontre des problèmes.

---

Je sais bien qu'aucun problème n'est insurmontable, et qu'il y a très facilement moyen de retrouver l'endroit ou un "imbécile touche à ce qu'il ne doit pas" ;) :D

Mais, si, d'un autre coté, au prix de relativement peu d'efforts (enfin, à moins que tu ne développe ton truc depuis cinq ans :roll:), il y a moyen, non seulement de faire en sorte d'éviter ce genre de problème, mais aussi d'éviter le cout d'un refactoring d'ici "quelques années", tu ne crois pas que ca vaut franchement la peine de s'accorder le temps nécessaire à un changement d'optique :question:

Citation:

---

Envoyé par koala01

Je présumes que tu as déjà pris soin d'enregistrer ta conf "par lot", dans le sens ou ta fonction write (ou read, selon le sens de travail ;) ) ressemble sans doute à

Code:

---

1 2 3 4 5 6 7

void singleton::write() { saveWindowConfig(); saveKeyConfig(); saveDifficultyConfig(); /* ...*/ }

---

chaque fonction se chargeant de sauvegarder (ou de lire, en core une fois) le lot d'informations qui l'intéresse, chaque fonction appelant d'autres fonctions traitant des lots plus particuliers ...

---

Citation:

---

Envoyé par koala01

Il suffit donc que tu rajoutes une fonction pour gérer un nouvel aspect de ta fenêtre pour que tu te trouves face à l'obligation de recompiler l'ensemble des modules (que ce soit en tout ou en partie) alors que tu aurais très bien pu n'avoir à recompiler que le module graphique (pour suivre mon exemple ;)), et encore... meme pas forcément l'ensemble du module graphique ;)
Je sais bien qu'aucun problème n'est insurmontable, et qu'il y a très facilement moyen de retrouver l'endroit ou un "imbécile touche à ce qu'il ne doit pas" ;) :D

---

Non justement, je n'ai rien fait de tel, c'est pas du tout l'optique. Le but est de faire quelque chose de complètement générique, justement afin de ne pas avoir tout retoucher des qu'on invente une nouvelle section.

Citation:

---

Envoyé par koala01

Au fil des cinq ans de développement, c'est devenu une espèce de monstre polymorphe dont on s'étonnerait presque qu'il ne fasse pas le café :D

---

J'y ai pensé. La partie config du jeu sera générée à la volée en fonction des clés dans le singleton. Donc on ne met dedans que les propriétés qu'on veut voir exposées à l'utilisateur final. Le reste se fait avec des defines ou autres (pour les tests, les "on verra plus tard" etc).
De plus, la plupart des unit tests sont faits sans que le singleton ne soit créé, donc les classes doivent pouvoir se démerder sans.

Citation:

---

Envoyé par koala01

Le gros problème, c'est que le singleton devient le "point de rencontre" de tous tes modules, et que chaque module dépend explicitement de ton singleton, en plus de toutes les dépendances plus "logiques"...

---

Avec ton design, j'aurais le même goulet d'étranglement au niveau du panneau de config, a part que le panneau de config a autrement plus de dépendances (graphique, input, gamestate) que mon singleton qui gère son truc dans son coin et envoie des events asynchrones.

Citation:

---

Envoyé par koala01

Mais, si, d'un autre coté, au prix de relativement peu d'efforts (enfin, à moins que tu ne développe ton truc depuis cinq ans :roll:), il y a moyen, non seulement de faire en sorte d'éviter ce genre de problème, mais aussi d'éviter le cout d'un refactoring d'ici "quelques années", tu ne crois pas que ca vaut franchement la peine de s'accorder le temps nécessaire à un changement d'optique :question:

---

Tout à fait, c'est pourquoi ton avis m'intéresse beaucoup. J'espère que tu ne vois pas dans cette discussion une simple querelle idéologique, c'est juste ma façon de raisonner, j'aime pas suivre les conseils juste parce qu'on me les donne, j'aime comprendre les tenants et aboutissants. S'il y a des problèmes que j'ai pas anticipé, je suis toujours preneur.
Mais on a tous le même travers : si on est confronté à une grosse erreur de design qui nous pose de gros problèmes et nous fait perdre plein de temps, on a tendance à refuser tout ce qui s'en approche. J'ai d'autres bons exemples (fragmentation mémoire par exemple). C'est pourquoi j'essaie de comprendre exactement les problèmes que tu as rencontré afin de vérifier si j'ai bien tout anticipé.

Rewpparo et koala01,

Vous avez eu une sacrée conversation grâce à moi finalement ... :D
Et je me dis que le jour où je pourrais comprendre tout ce que vous êtes raconté, çà sera le pied mais en attendant je galère...

Alors je me permets de demander encore de l'aide parce que pour vous çà a l'air tellement facile et que pour moi, c'est tellement compliqué.

Est-ce que vous pourriez m'aider à coder la méthode
static bool c_usn_file_registry::instancier_singleton(nmutility::CString nom_fichier)
qui crée le singleton « usn_file_registry », lit le fichier .reg (fichier base de registres) donné en argument, et construit une structure de données interne (basée sur « CStdMap ») avec l'ensemble des valeurs contenues dans le fichier.

Pour l'aspect singleton, maintenant j'ai compris, pour la lecture du fichier je devrais m'en sortir aussi mais alors pour mettre les valeurs lues dans la structure CStdMap (qui se trouve dans le fichier que j'ai joint) alors là dur ! :?

Merci.

Tapiou.

Vu comment on a highjacké ton sujet, on va finir de t'aider :)
Alors chaque dans ton fichier .reg tu dois avoir des ensemble clé/valeur sous forme de string. D'abord il te faut un CStdMap<string, string> quelque part dans ta classe, appelons le map. Pour chaque couple que tu récupère dans le .reg, tu as juste a faire :

Code:

---

map.insert(clé, valeur)

---

C'est en fait juste un wrapper pour std::map il me semble, ca marche plus ou moins pareil.
Ca répond à ta question ?

Merci Rewpparo.

Je ne comprends pas bien.
J'ai joint un exemple de fichier .reg (que j'ai renommé en .txt sinon je ne pouvais pas le joindre).

Dans ma tête, j'imaginais que la structure à construire représentait dans le cas de ce fichier, 12 items avec à chaque fois 3 valeurs associées :

Ce qui donnerait pour le premier item :
- La chaîne de caractères de type HKEY
Exple : [HKEY_LOCAL_MACHINE\SOFTWARE\Entreprise\UXT\MINMGR]

- La chaîne représentant le flag
Exple : "TRACE_DIRECTORY"

- La chaîne représentant la valeur
Exple : "JOKER_TARGET\\Data\\Logs\\Traces\\Command"

et pour le deuxième item :
[HKEY_LOCAL_MACHINE\SOFTWARE\Entreprise\UXT\MINMGR]
"DragAndDrop"
dword:00000000

et ainsi de suite pour les 10 autres items.

Et donc que ce que tu as appelé map serait un CStdMap<string, string, string> avec 3 fois string donc.
Mais je vois bien que ce n'est pas possible et que c'est toi qui a raison, mais alors je ne comprends où est stockée l'info du type " [HKEY_LOCAL_MACHINE\SOFTWARE\Entreprise\UXT\MINMGR]"

Pour toi, dans un map.insert(clé, valeur), clé aurait par exemple pour valeur "TRACE_DIRECTORY" et valeur aurait pour valeur "JOKER_TARGET\\Data\\Logs\\Traces\\Command" ?

Mais alors où est traitée l'information "[HKEY_LOCAL_MACHINE\SOFTWARE\Entreprise\UXT\MINMGR]" ?

Gloups ...

Merci.

Tapiou.

Citation:

---

Envoyé par Rewpparo

Non justement, je n'ai rien fait de tel, c'est pas du tout l'optique. Le but est de faire quelque chose de complètement générique, justement afin de ne pas avoir tout retoucher des qu'on invente une nouvelle section.

---

Donc, si je te comprends bien, ton singleton maintient une collection proche d'une pair string / string et renvoie le tout à qui le demande, obligeant celui qui a posé la question à

1. vérifier la clé pour savoir si elle lui convient
2. convertir la valeur en une valeur utilisable

(si c'est une pair ou une structure composée d'une string et d'un boost.any, ca revient quasiment au même ;))

Or, il ne faut pas oublier que la comparaison de chaines compte parmi les processus de comparaison les plus lents que l'on puisse trouver, d'une part, et d'autre part que tu rend la classe qui utilise l'information responsable de la conversion de l'information dans les deux sens :aie:

j'ai beau être un ardent défenseur de la généralisation et du principe "open close", je ne suis vraiment pas convaincu par l'efficacité de la chose :aie:

D'autant plus que le fait de gérer toute ta collection de propriétés sauvegardées sous forme de pair string, string (ou équivalent) pour la sauvegarde n'est absolument pas incompatible avec... la notion de "décentralisation" de l'information que je défend ;)

Citation:

---

J'y ai pensé. La partie config du jeu sera générée à la volée en fonction des clés dans le singleton. Donc on ne met dedans que les propriétés qu'on veut voir exposées à l'utilisateur final. Le reste se fait avec des defines ou autres (pour les tests, les "on verra plus tard" etc).
De plus, la plupart des unit tests sont faits sans que le singleton ne soit créé, donc les classes doivent pouvoir se démerder sans.

---

Es tu seulement sur qu'il n'y a pas une fonction que tu as oubliée dans une classe quelconque qui fait un Singleton::instance().getMachinChose :question:

Es tu, surtout, sur que cela n'arrivera jamais :question:

Si tu travailles en équipe, es tu sur que ton voisin de poste a compris la manière dont tu voulais utiliser ton singleton :question:

Dans l'exemple que je donnais la tantot, le gros problème ne vient pas du singleton en tant que tel, le problème vient de toutes les classes qui y accèdent alors qu'elles n'auraient pas lieu d'y accéder :aie:

Du coup, lorsqu'il s'agit d'externaliser une partie de l'info, tu repères assez rapidement certains points auxquels tu t'attends effectivement à ce qu'il y ait un accès à la donnée que tu veux décentraliser, mais c'est sans compter sur les 2000 autres fichiers du projet que tu ne penseras peut etre pas à vérifier :aie:

Citation:

---

Avec ton design, j'aurais le même goulet d'étranglement au niveau du panneau de config, a part que le panneau de config a autrement plus de dépendances (graphique, input, gamestate) que mon singleton qui gère son truc dans son coin et envoie des events asynchrones.

---

Non, ou du moins, il sera largement diminué, par ce que les dépendances s'inversent : l'utilisateur et l'utilisé sont différents

Ce n'est plus quatre ou cinq modules qui dépendent (comprend : tous les modules utilisent une partie du singleton qui leur est propre, mais on accès aux informations qui ne les concernent pas) d'un singleton, mais un module qui dépend (comprend: qui utilise une partie) des quatre ou cinq autres ;)

En effet, dans le desing que je défends, c'est le panneau de configuration qui se charge d'invoquer les accesseurs et les mutateurs, alors que les autres modules n'ont meme pas besoin de savoir que le panneau de configuration existe ;)

De plus, au lieu d'avoir "en vrac" les XXX informations relatives à tous tes modules et de devoir en "faire le tri" (ah, ca, c'est pour telle partie du panneau de configuration, ah, ca, c'est pour telle autre... tiens? comment ca se fait que j'ai cette information là, moi ???) tu ne disposes que des informations propres au module qui t'intéressent ;)

Citation:

---

Tout à fait, c'est pourquoi ton avis m'intéresse beaucoup. J'espère que tu ne vois pas dans cette discussion une simple querelle idéologique, c'est juste ma façon de raisonner, j'aime pas suivre les conseils juste parce qu'on me les donne, j'aime comprendre les tenants et aboutissants. S'il y a des problèmes que j'ai pas anticipé, je suis toujours preneur.

---

Ne t'en fais pas, j'ai toujours considéré que c'est en confrontant ses idées qu'il était possible d'évoluer ;)

Et je ne prends également le temps de comprendre les tenants et les aboutissants avant de me faire mon propre avis ;)

Par contre, je suis relativement pugnasse quand il s'agit de défendre mon point de vue... mais tu l'avais surement remarqué ;) :D

Citation:

---

Mais on a tous le même travers : si on est confronté à une grosse erreur de design qui nous pose de gros problèmes et nous fait perdre plein de temps, on a tendance à refuser tout ce qui s'en approche. J'ai d'autres bons exemples (fragmentation mémoire par exemple). C'est pourquoi j'essaie de comprendre exactement les problèmes que tu as rencontré afin de vérifier si j'ai bien tout anticipé.

---

Ceci dit, on est déjà d'accord sur le principal : le singleton est mal, simplement, je suis un chouia plus extrêmiste que toi sur le sujet :D

Mais il est vrai que, une fois que tu t'es heurté une fois, comme je l'ai fait, au fait que tu avais un singleton qui semble faire exactement ce dont tu as besoin (et qui, de prime abord, limite les dépendances) qui, sans rien dire à personne, en invoque un autre qui va initialiser tous les autres (dont tu n'as pas besoin!!! ) parce qu'il sert de "centralisateur", il y a vraiment de quoi devenir prudent ;)

Citation:

---

Envoyé par tapiou

Merci Rewpparo.

Je ne comprends pas bien.
J'ai joint un exemple de fichier .reg (que j'ai renommé en .txt sinon je ne pouvais pas le joindre).

Dans ma tête, j'imaginais que la structure à construire représentait dans le cas de ce fichier, 12 items avec à chaque fois 3 valeurs associées :

Ce qui donnerait pour le premier item :
- La chaîne de caractères de type HKEY
Exple : [HKEY_LOCAL_MACHINE\SOFTWARE\Entreprise\UXT\MINMGR]

- La chaîne représentant le flag
Exple : "TRACE_DIRECTORY"

- La chaîne représentant la valeur
Exple : "JOKER_TARGET\\Data\\Logs\\Traces\\Command"

et pour le deuxième item :
[HKEY_LOCAL_MACHINE\SOFTWARE\Entreprise\UXT\MINMGR]
"DragAndDrop"
dword:00000000

et ainsi de suite pour les 10 autres items.

Et donc que ce que tu as appelé map serait un CStdMap<string, string, string> avec 3 fois string donc.
Mais je vois bien que ce n'est pas possible et que c'est toi qui a raison, mais alors je ne comprends où est stockée l'info du type " [HKEY_LOCAL_MACHINE\SOFTWARE\Entreprise\UXT\MINMGR]"

Pour toi, dans un map.insert(clé, valeur), clé aurait par exemple pour valeur "TRACE_DIRECTORY" et valeur aurait pour valeur "JOKER_TARGET\\Data\\Logs\\Traces\\Command" ?

Mais alors où est traitée l'information "[HKEY_LOCAL_MACHINE\SOFTWARE\Entreprise\UXT\MINMGR]" ?

Gloups ...

Merci.

Tapiou.

---

Ce qui est entre crochet représente l'endroit dans la base de registre où l'item va devoir aller...

la deuxième chaine (ex : DragAndDrop ) représente la clé de registre et la troisième (si elle existe) représente la valeur à lui donner (en fait, le type de valeur qu'elle prend, suivi de la valeur)

Deux chaines de caractères ne seront donc pas suffisantes, mais tu pourrait envisager de créer une structure proche de:

Code:

---

1 2 3 4 5 6

struct RegistryItem { std::string path; // pour [HKEY_LOCAL_MACHINE\SOFTWARE\Entreprise\UXT\MINMGR] std::string key; // pour DragAndDrop std::string value; // pour dword:00000000 , si present };

---

Ta map deviendrait donc une map<string, RegistryItem>, et la valeur servant de clé serait celle correspondant à key ;)

Merci koala01 :D
Mais je ne comprends pas encore tout :calim2:

Ma map deviendrait donc une map<string, RegistryItem> ?

Mais le string dans map<string, ...>, il sert à quoi dans ce cas ?
Les 3 string correspondant à path, key et value sont déjà dans RegistryItem, non ?


Quand je ferais un map.insert(clé, valeur), je ne comprends pas ce que vaudra clé et ce que vaudra valeur.
Clé sera dans l'exemple DragAndDrop ? Et valeur, dword:00000000 ?

Merci.

Tapiou.

A mon avis, elle vaudrait plutot la valeur de key, meme si, en l'occurrence, un set pourrait aussi bien faire l'affaire (avec le foncteur ad-hoc ;))

Maintenant, la clé pourrait etre n'importe quoi aussi, qui serait peut etre plus explicite que la clé que l'on trouve dans le fichier reg, voire, la concaténation de la valeur de path et de la valeur de key (car il est possible d'avoir deux clés identiques dans des chemins différents) ;)

Le tout dépend de l'usage que tu en feras, mais, en gros, la clé de la map devrait représenter un identifiant unique par lequel il t'est commun d'essayer de retrouver les éléments.

A partir de là, le fait de prendre la valeur de key (dans la structure que je présentes) semble pour le moins logique, mais tu restes tout à fait libre de choisir n'importe quoi d'autre qui pourrait, qui sait, s'avérer plus adapté ;)

Réveil en pleine nuit ....

Merci encore

Mais le string dans map<string, ...>, il sert à quoi, je ne comprends pas.

Merci.

Je vais me recoucher ... :calim2:

S'il y a deux clé (le chemin et la clé), c'est bizarre d'utiliser un map. Mettre l'un des deux en clé du map ne te sert pas, car il faut que les deux soient les mêmes. Moi ce que j'aurais fait c'est un vecteur de RegistryItem de Koala, que tu parcours jusqu'à trouver l'élément dont la clé et le chemin correspondent à la requête, et tu revoie la troisième valeur du même élément.
Si ton boss t'impose un map, il avait peut être une idée en tête. Par exemple agréger le chemin et la clé en les séparant par un caractère spécial. par exemple
clé du map : "[HKEY_LOCAL_MACHINE\SOFTWARE\Entreprise\UXT\MINMGR] : TRACE_DIRECTORY"
valeur : "JOKER_TARGET\\Data\\Logs\\Traces\\Command"

Citation:

---

Envoyé par koala01

Ceci dit, on est déjà d'accord sur le principal : le singleton est mal, simplement, je suis un chouia plus extrêmiste que toi sur le sujet :D

---

Ouais, mais l'extrémisme a une raison, et maintenant je la vois. En concevant le truc j'ai pensé a la plupart des problèmes, mais je serais très attentif à l'émergence de ces problèmes. Normalement rien que le fait que tout ce qu'on met dedans soit visible par l'utilisateur, combiné aux unit tests sans le singleton, devraient suffire je pense a éviter le syndrome de l'hydre. Mais si ca dégénère, on changera vite.

Citation:

---

Envoyé par Rewpparo

Ouais, mais l'extrémisme a une raison, et maintenant je la vois. En concevant le truc j'ai pensé a la plupart des problèmes, mais je serais très attentif à l'émergence de ces problèmes. Normalement rien que le fait que tout ce qu'on met dedans soit visible par l'utilisateur, combiné aux unit tests sans le singleton, devraient suffire je pense a éviter le syndrome de l'hydre. Mais si ca dégénère, on changera vite.

---

Je ne crois sincèrement pas que tes unit tests puissent ou que le fait que tout ce qui se trouve dans le singleton soit accessible par l'utilisateur (d'ailleurs, n'est ce pas plutot l'inverse :question:) ne puisse garantir quoi que ce soit...

Il n'existe, à ma connaissance, aucune possibilité de s'assurer des appels de fonctions qui se trouvent à l'intérieur d'une fonction testée, et tu ne peux donc absolument pas, à moins de placer un point d'arret sur la fonction Singleton::instance(), t'assurer que l'appel au singleton ne se fait que "là où c'est autorisé" :aie:

Maintenant, je me trompe peut etre lourdement ;)

Citation:

---

Envoyé par koala01

Il n'existe, à ma connaissance, aucune possibilité de s'assurer des appels de fonctions qui se trouvent à l'intérieur d'une fonction testée, et tu ne peux donc absolument pas, à moins de placer un point d'arret sur la fonction Singleton::instance(), t'assurer que l'appel au singleton ne se fait que "là où c'est autorisé" :aie:

---

La méthode instance ne fait que renvoyer un pointeur initialisé a 0. Si on n'appelle pas Singleton::create() ou si on a appelé Singleton::destroy() ca reste 0. Donc si on l'utilise ca plante, ou au moins ca apparait sur valgrind.

Citation:

---

Envoyé par Rewpparo

La méthode instance ne fait que renvoyer un pointeur initialisé a 0. Si on n'appelle pas Singleton::create() ou si on a appelé Singleton::destroy() ca reste 0. Donc si on l'utilise ca plante, ou au moins ca apparait sur valgrind.

---

A priori, instance() devrait invoquer create si l'objet n'existe pas :aie:...

Ne serait-ce parce que, autrement, tu forces l'utilisateur à utiliser ton singleton dans une logique définie, qu'il aura vite fait d'oublier ;)

C'est, entre autre, la raison pour laquelle la méthode que j'indique est, à la limite, préférable : comme je ne recours pas à l'allocation dynamique de la mémoire, je ne risque pas d'oublier de détruire le singleton une fois qu'il n'est plus utile (il sera détruit en meme temps que les variables globales, en gros), et je peux toujours le recréer "à la demande" si, pour une raison ou une autre, j'en ai besoin lors du "nettoyage final" de l'application, après qu'il ait été détruit (vu que les variables sont toujours détruites dans l'ordre de leur création) ;)

Après, je t'accorde le fait que cela n'a pas énormément d'importance pour un gestionnaire de configuration, mais, dans le cas d'un gestionnaire de log (qui est une autre raison de recourir à un singleton :D), il est toujours utile de pouvoir l'utiliser "n'importe où" :D

Et puis, ca fonctionne avec la méthode que tu as indiquée au début de la discussion, mais pas avec celle que j'ai moi meme indiquée ;)

De plus, valgrind n'est, a priori, pas un outil de tests unitaires: il faut l'utiliser "en sus" ;)

C'est rigolo, on a deux manières complètement différentes d'aborder le problème, chacune avec sa logique.
Les choix que je fais sont logiques dans ma conception du truc, mais absolument pas dans la tienne, et réciproquement. Alors qu'au final tout se tient.
Toi tu as une optique où tu évites les abus par le design.
Moi une où je met des garde fou contre les abus car le design, même s'il est dangereux et que je le sais, me simplifie quand même grandement la tâche pour certaines subtilités de mon programme.
Nous sommes tous les deux conscients des dangers des singletons, mais avons choisi de les gérer de manière différente.
Peut être qu'avec l'expérience je me rangerais à ton idée.

Citation:

---

Envoyé par Rewpparo

C'est rigolo, on a deux manières complètement différentes d'aborder le problème, chacune avec sa logique.
Les choix que je fais sont logiques dans ma conception du truc, mais absolument pas dans la tienne, et réciproquement. Alors qu'au final tout se tient.
Toi tu as une optique où tu évites les abus par le design.
Moi une où je met des garde fou contre les abus car le design, même s'il est dangereux et que je le sais, me simplifie quand même grandement la tâche pour certaines subtilités de mon programme.
Nous sommes tous les deux conscients des dangers des singletons, mais avons choisi de les gérer de manière différente.

---

Oui, c'est tout à fait ca :D

Cependant, les décisions de desing de debut de projet sont sans doute les plus importants dans la durée de vie du projet, car ils vont conditionner l'ensemble des évolutions futures, et tu es très certainement conscient qu'il y en aura, je présume :D

Or, de mon avis, je ne suis pas tout à fait persuadé que les décisions que tu as prises te facilite *tellement* la vie que cela par rapport aux alternatives, simplement parce que, les informations ne sont pas accessibles directement au départ de l'objet qui en aura besoin (il faudra, quoi qu'il arrive, passer par une classe qui se charge de gérer ces informations).

Par contre, ce que je trouve dangereux, c'est de mettre "tous les œufs dans le même panier" dans le sens où, si tu décides un jour de modifier la configuration de la fenêtre dans le gameplay (par exemple ;)), il n'y aura strictement rien qui pourra t'en empêcher.

L'erreur a beau être facile à débugger et à traquer, tu garde la possibilité de le faire, alors qu'en inversant les dépendances et en décentralisant les informations, ta vie ne serait très certainement pas plus compliquée, mais tu aurais une sécurité accrue quant à l'endroit où les changements s'effectueraient ;)

Cela aurait en outre l'énorme avantage de te simplifier pour grande part la vie, simplement parce que tu n'aurais pas de garde fous à placer (et donc, pas de contrôles à effectuer que tu risque d'avoir oublier qu'il fallait les mettre en place dans trois mois) ;)

Personnellement, je pars du principe que je ne suis pas meilleur humain que n'importe qui d'autre, et que je risque d'oublier, d'une fois sur l'autre, les contrôles que je dois mettre en place, surtout sur un gros projet ;)

Par contre, en sachant cela, je décide de bloquer par design les cas "bateau" qui risquent de me poser problème ;)

L'excès de prudence ne nuit jamais en programmation ;)

Ouh la la la conversation, je la lirai en journée parce que là en soirée, j'ai du mal ... 8O

Comme çà a l'air vraiment de vous intéresser, mon chef m'a écrit çà après que je lui ai demandé :

- Pourquoi instancier_singleton retourne un bool ?
- Ne faut-il pas une méthode pour détruire le singleton quand tu n’en as plus besoin ?
- Pour les tests des méthodes, je fais comment ?

Réponse :
"Le principe d'un singleton c'est que l'instance est unique dans le programme et permanente (variable globale, membre static de la classe). Il y a donc une méthode pour instancier le singleton, appelée la première fois où on en a besoin, puis un get_singleton pour récupérer l'instance préalablement créée (donc un singleton classique, c'est la méthode get_singleton elle-même qui instancie le singleton s'il n'existe pas déjà, ici le principe est un peu différent). Ici instancier_singleton fait plus que simplement instancier le singleton, puisqu'elle charge aussi le fichier et initialise ses structures internes, c'est pourquoi elle retourne un booléen pour indiquer un éventuel échec ; de plus elle a besoin d'un paramètre (le nom du fichier), c'est pourquoi elle n'est pas appelée directement par get_singleton.
Pour les tests, tu peux créer un petit projet de test unitaire"


Euh ... sinon ... il faut que j'obéisse au chef qui je le rappelle veut une structure de données interne (basée sur CStdMap) avec l'ensemble des valeurs contenues dans le fichier.


Sinon, Koala01, tu as dit :
"A mon avis, elle vaudrait plutot la valeur de key, meme si, en l'occurrence, un set pourrait aussi bien faire l'affaire (avec le foncteur ad-hoc )"

Je ne comprends pas, il n'y a pas de set dans CStdMap.

Et je ne comprends toujours pas :
Si la map est une map<string, RegistryItem>, le string dans map<string, RegistryItem>, il sert à quoi ?

Bon be peut-être que demain en relisant le tout, je comprendrais mieux.... mais j'ai un doute :calim2:

Merci en tout cas de cette participation ;)

Tapiou.

Citation:

---

Envoyé par tapiou

Ouh la la la conversation, je la lirai en journée parce que là en soirée, j'ai du mal ... 8O

Comme çà a l'air vraiment de vous intéresser, mon chef m'a écrit çà après que je lui ai demandé :

- Pourquoi instancier_singleton retourne un bool ?
- Ne faut-il pas une méthode pour détruire le singleton quand tu n’en as plus besoin ?
- Pour les tests des méthodes, je fais comment ?

Réponse :
"Le principe d'un singleton c'est que l'instance est unique dans le programme et permanente (variable globale, membre static de la classe). Il y a donc une méthode pour instancier le singleton, appelée la première fois où on en a besoin, puis un get_singleton pour récupérer l'instance préalablement créée (donc un singleton classique, c'est la méthode get_singleton elle-même qui instancie le singleton s'il n'existe pas déjà, ici le principe est un peu différent). Ici instancier_singleton fait plus que simplement instancier le singleton, puisqu'elle charge aussi le fichier et initialise ses structures internes, c'est pourquoi elle retourne un booléen pour indiquer un éventuel échec ; de plus elle a besoin d'un paramètre (le nom du fichier), c'est pourquoi elle n'est pas appelée directement par get_singleton.
Pour les tests, tu peux créer un petit projet de test unitaire"


Euh ... sinon ... il faut que j'obéisse au chef qui je le rappelle veut une structure de données interne (basée sur CStdMap) avec l'ensemble des valeurs contenues dans le fichier.


Sinon, Koala01, tu as dit :
"A mon avis, elle vaudrait plutot la valeur de key, meme si, en l'occurrence, un set pourrait aussi bien faire l'affaire (avec le foncteur ad-hoc )"

Je ne comprends pas, il n'y a pas de set dans CStdMap.

Et je ne comprends toujours pas :
Si la map est une map<string, RegistryItem>, le string dans map<string, RegistryItem>, il sert à quoi ?

Bon be peut-être que demain en relisant le tout, je comprendrais mieux.... mais j'ai un doute :calim2:

Merci en tout cas de cette participation ;)

Tapiou.

---

Une map, c'est un tableau associatif qui crée une association entre une clé, que l'on utilisera pour rechercher les éléments et une valeur, que l'on utilisera dans le programme.

La clé se ta CstdMap doit donc représenter la manière la plus fréquente par laquelle tu compte rechercher les éléments dont tu dispose dans la map.

C'est la raison pour laquelle je me dis que, selon les besoins, la clé pourrait prendre la meme valeur celle de key voire, si tu te trouves avec des clés portant le meme nom mais positionnée sur des chemins différents, la concaténation de la valeur de paht et de la valeur de key.

Un set (c'est sans doute CstdSet chez toi) est une collection d'éléments particulièrement optimisés pour retrouver des éléments, car il utilise les arbres binaires, un peu à l'instar de la map, si ce n'est que c'est carrément l'élément qui sert de clé (il n'y a pas de distinction entre la clé et l'élément, si tu préfères ;))

Tu pourrais donc parfaitement envisager d'écrire un opérateur "plus petit que" qui permettra de comparer les différents éléments que tu trouverais dans le set, et qui ressemblerait à quelque chose comme

Code:

---

1 2 3 4 5 6 7 8 9 10

bool operator<(RegistryItem const & first, RegistryItem const & second) { /* pour un tri uniquement sur la valeur de key */ return first.key < second.key; /* OU OU OU pour un tri sur la concaténation de la valeur de path   * et de la valeur de key   */ return first.path < second.path || (first.path == second.path && first.key <second.key); }

---

Il faut cependant etre conscient qu'il existe une autre différence entre la map et le set...

En effet, étant donné que la map effectue son tri sur la clé, la valeur (la structure RegistryItem ici) peut évoluer de manière indépendante, tout en gardant la meme clé.

Tu peux donc envisager de modifier la valeur (ici, la structure RegistryItem) tant que les modifications que tu apportes n'interviennent pas sur la valeur de l'identifiant unique (par exemple, sur la valeur de key et / ou la valeur de path, en fonction de ce que tu auras chois pour représenter ce fameux identifiant unique).

Tu pourrais donc parfaitement envisager un code proche de

Code:

---

maMap.find("DragAndDrop").second.value="dword:00000001".

---

Pour ce qui est du set, par contre, étant donné que c'est l'élément lui-même qui sert de clé pour le tri, la fonction find renvoie d'office un const_iterator, ce qui interdit de modifier l'élément renvoyé.

On ne pourrait donc pas écrire un code proche de

Code:

---

*(leSet.find("DragAndDrop")).value="dword:00000001"

---

et, pour effectuer ce genre de changement, il faudrait travailler en trois temps :
récupérer l'itérateur sur l'objet que l'on veut modifier
supprimer l'ément ainsi obtenu
insérer l'élément modifié.

Cela pourrait ressembler à quelque chose comme

Code:

---

1 2 3 4 5 6 7

RegistryItem newItem; newItem.value = "dword:00000001"; std::set<RegistryItem>::const_iterator it = leSet.find("DragAndDrop"); newItem.key = it->key; newItem.path = it->path; leSet.erase(it); leSet.insert(newItem);

---

Les deux solutions sont envisageables, il faut "simplement" essayer de déterminer si l'on va essayer régulièrement d'apporter des modifications aux élément de la collection, ou non ;)

Koala01,

Je manque de temps pour lire attentivement ta réponse, je vais le faire ce WE.

Mais déjà, je te dis merci ! :ccool:

Tapiou.

Bonjour Koala01,

Effectivement, il y a classe CstdSet chez moi. J'ai demandé au chef vendredi si je pouvais l'utiliser au lieu de CStdMap mais il ne veut pas.

Donc je dois travailler en n'utilisant que CStdMap.

Tapiou.

Bonjour Koala01 et Rewpparo,

J'ai écrit une partie du code conformément aux spé de mon boss grâce à toutes les indications que vous m'avez données.

En fait vous avez fait la conception et moi le codage avec votre aide ;)

Est-ce que vous pourriez le relire et me dire ce que vous en pensez ?
Je voudrais savoir si je ne me suis pas complètement viander ...

La méthode lire_entier donnerait çà :

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

int c_usn_file_registry::lire_entier(nmutility::CString nom_chemin, nmutility::CString nom_valeur) { // Exple : lecture de la valeur de "DragAndDrop" de [HKEY_LOCAL_MACHINE\SOFTWARE\Entreprise\UXT\MINMGR]   nmutility::CStdMap<nmutility::CString, RegistryItem> ::iterator im; RegistryItem RegistryItem;   std::string cle; cle = nom_chemin + " : " + nom_valeur; im = _map.find(cle) ; // Par exple, (*im).second.value contient dword:00000000   std::string valeur; valeur = (*im).second.value;   size_t Pos2Points; Pos2Points=valeur.find_first_of(":"); std::string ValeurEntier; ValeurEntier = valeur.substr(Pos2Points+1); // On récupère ce qu'il y a après le :   // Conversion de la string ValeurEntier en entier std::istringstream iss(ValeurEntier); int num; iss >> num;   return(num); }

---

D'avance, merci.

Tapiou.

Nota : j'espère que je n'abuse pas trop ... :oops:

Moi ca me semble bien. Avant de convertir la seconde partie de valeur en entier, tu pourrais vérifier que ce qu'il y a avant le : est bien "DWORD" ou autre chose de compatible, afin de renvoyer une erreur si c'est pas le cas.
Mais c'est optionnel.

Bonsoir Rewpparo

Merci :)

Je vous fais la hola :
:lahola:

à toi et à Koala01 pour vous remercier pour toutes les infos.

Tapiou.

Bon courage pour la suite :)