Initialisation des instances de classe global

Bonjour.

J'ai un .cpp qui encapsule une map global et 2-3 fonctions qui la manipule :

Code:

---

1 2 3 4 5 6 7 8 9 10

namespace { std::map<std::string,int > maMap;   }   void addElement(const std::string &name, int i) { maMap[name] = i; }

---

Dans d'autre fichier cpp la fonction addElement est appelé lors de l'initialisation d'une variable global de cette manière

Code:

---

1 2 3 4 5 6 7 8 9

namespace { bool Init() { addElement("test",10); return true; } bool initialized = Init(); }

---

seulement ça crash. C'est comme si la map n'était pas encore initialisée. Si j'utilise un pointeur ça fonctionne.

J'ai du mal à comprendre pourquoi. Es ce que l'appel au constructeur des objets globaux se fait après l'initialisation des variables globales POD?

En gros ce que je veux faire :
1- j'ai une map qui représente un singleton.
2- j'ai une fonction qui permet d'enregistrer une information dans cette map.
3- l'enregistrement de cette information doit être faite qu'une seule fois.

le deuxième bout de code est il correcte? je fait de temps en temps cela quand je doit initialiser des chose global. Comme par exemple une fonction d'initialisation d'un framework. J'utilise un bouleen global qui est initialisé par l'appel d'une fonction. Cette fonction va ainsi initialiser les partie globales.

:merci:

Peut être que je me trompe,

mais un namespace n'est pas, me semble t'il, un bloc permettant l'exécution de code et donc à fortiori l'appel d'une fonction en l'occurence Init.

[EDIT]Quoique ce code compile donc cela doit être valable. C'est en langage que ce type d'initialisation n'est pas autorisée.

Tu as schématiquement 2 variables globales (ta map, et ton booléen). Tu les initialize dans deux fichiers cpp séparés.

Rien n'indique dans quel sens les deux seront construits (alors que dans un même fichier, les variables globales sont construites dans leur ordre d'apparition). Tu te trouves là certainement à avoir le booléen qui est construit alors que la map ne l'a pas encore été => BOOM !

Il y a une astuce pour t'assurer que ça puisse quand même marcher (recherche nifty counter pour plus d'infos), mais c'est très bas niveau, et il faut faire attention à des histoires d'alignement, de placement new,...

Une solution plus simple est de faire de ta map un objet qui n'est plus global. Par exemple, si tu en fais une variable statique à l'intérieur d'une fonction, tu as la garantie qu'elle sera initialisée au premier appel de la fonction (en C++11, tu as même la garantie que ça se passe bien en multithread aussi, mais certains compilos n'implémentent toujours pas ça (donc Visual C++), te forçant pour avoir l'équivalent à définir un singleton avec lock sur la variable...)

Voici la version C++11:

Code:

---

1 2 3 4 5

std::map<std::string,int > &getMap() { static std::map<std::string,int > maMap; return maMap; }

---

Mais une meilleure solution réside probablement par la suppression de ces variables globales :)

Salut,

Citation:

---

Envoyé par JolyLoic

Mais une meilleure solution réside probablement par la suppression de ces variables globales :)

---

voire, de regrouper au minimum l'implémentation de l'ensemble au sein d'un seul et même fichier *.cpp, même si les déclarations des fonctions peuvent, en l'occurrence, être séparées ;)

Merci JolyLoic.
C'est bien ce que je pensais. Ce qui m'étonne c'est si je remplacer le bout de code par

Code:

---

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

namespace { std::map<std::string,int > * maMap = NULL;   }   void addElement(const std::string &name, int i) { if(maMap == NULL) maMap = new std::map<std::string,int >(); maMap[name] = i; }

---

maMap était bien mis à NULL. Mais c'est peut être un coup de chance.

Ta solution est celle que j'avais implémenté au final.

Sinon, je ne veux pas regrouper un minimum car c'est justement pour bien séparer les dépendances que je voulais faire cela. Et fait j'ai une interface, et chaque implémentation de cette interface encapsule un framework. Et je veux pouvoir facilement enlever un framework.
Pour être plus précis, ma map sert de factory light. C'est une map de std::fonction; Et la classes'enregistre à la factory par :

Code:

---

1 2 3 4 5 6 7 8 9

namespace { bool Init() { adduneClasse("Ma classe",[](){return new MaClass();}); return true; } bool initialized = Init() };

---

un pointeur est un POD et les POD sont initialises avant tout
std::map n'est pas un POD, c'est une instance de classe qui n'est valable qu'apres que le constructeur ait ete appele.
si tu as un pointeur ca marche (ca reste cradoc).

Citation:

---

Envoyé par screetch

(ca reste cradoc).

---

Qu'es ce qui te semble cradoc?

Le côté pointeur, qu'il faut faire attention à supprimer, ce qui ajoute encore une méthode à l'interface. Et l'ajout du test pour la première initialisation.
Avec la solution du static, on ne se soucie pas de ce(s) "problème(s)" :)

Citation:

---

Envoyé par Bousk

Le côté pointeur, qu'il faut faire attention à supprimer, ce qui ajoute encore une méthode à l'interface. Et l'ajout du test pour la première initialisation.
Avec la solution du static, on ne se soucie pas de ce(s) "problème(s)" :)

---

Ha oui ça, je suis d'accord ^^.

Citation:

---

Envoyé par yan

Qu'es ce qui te semble cradoc?

---

* un pointeur sur un objet a semantique de valeur
* tu leakes un std::map
* tu executes le if a chaque addElement
* tu a resolus un probleme de l'architecture, mais tu ne t'es pas assure que ce genre de probleme ne pouvait pas arriver encore une fois (si tu utilises cout, par exemple, ou un logger... etc), en gros tu as gueri un symptome mais pas la maladie derriere.

Citation:

---

Envoyé par screetch

* un pointeur sur un objet a semantique de valeur
* tu leakes un std::map
* tu executes le if a chaque addElement
* tu a resolus un probleme de l'architecture, mais tu ne t'es pas assure que ce genre de probleme ne pouvait pas arriver encore une fois (si tu utilises cout, par exemple, ou un logger... etc), en gros tu as gueri un symptome mais pas la maladie derriere.

---

c'est bien pour cela que je voulais comprendre ^^
Merci pour les explications.