Lire un fichier .reg + pb singleton

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 :)