Variable globale modifiée dans une fct et réinitialisée dans une autre fct

Bonjour,

J'ai déclaré une variable globale "factsPhone" comme étant une liste de faits (classe Fact) dans un fichier header "initialization.h" et j'ai crée une fonction "initializeFactsPhone()" pour remplir "factsPhone" comme suit :

"initialization.h" :

Code:

---

1 2 3 4 5 6 7 8 9 10

list<Fact> * factsPhone = new list<Fact> (); //facts of phone void initializeFactsPhone(){   Fact f1 (lp1, "justified", "collected"); Fact f2 (lp2, "justified", "collected"); Fact f3 (lp3, "justified", "collected"); factsPhone->push_back(f1); factsPhone->push_back(f2); factsPhone->push_back(f3); }

---

Dans un 2ème fichier Entity.cc, j'ai créé deux fonctions : la première sert à appeler la fonction "initializeFactsPhone()" pour initialiser la variable globale "factsPhone" et la 2ème fonction sert à gérer la liste "factsPhone comme suit :

Entity.cc :

Code:

---

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

#include "initialization.h" ... void Entity::initialize() { if (strcmp("phone", getName()) == 0) { .... initializeFactsPhone(); .... }   void Entity::handleMessage(cMessage *msg) { ev << "factsPhone : " << factsPhone->empty() << endl; //afficher 1 : liste remplie; 0 : liste vide int i=0; while (!selectedRules->empty()) {.... } }

---

Mon programme commence par exécuter la fonction Entity::initialize(), j'ai pu afficher le contenu de la liste "factsPhone" dans la même fonction Entity::initialize().
Cependant, lorsque mon programme exécute la fonction Entity::handleMessage, la liste factsPhone est vide!!! le programme affiche "1" pour "factsPhone->empty()".

Je soupçonne que c'est un problème de gestion de variable globale modifiée au sein de la fonction "Entity::initialize()" et réinitialisée dans l'autre fonction "Entity::handleMessage".

J'ai modifié la déclaration de "factsPhone" en rajoutant une fois "static" et une fois "extern" mais ça ne marche toujours pas.

Comment gérer une variable globale modifiée par toutes les fonctions et non réinitialisée pour chaque fonction ?

Pourriez vous SVP m'aider?

Je vous remercie d'avance.

Merci de mettre ton code dans la balise idoine.

Je m'excuse mais je n'ai pas pu modifier mon message pour mettre le code dans la balise.
Dorénavant je vais le faire, pourriez vous m'indiquer comment le faire?

Je ne vois rien dans votre code qui permet d'affirmer que la méthode "initializeFactsPhone" soit obligatoirement appelée avant la méthode "handleMessage".

Evitez les variables globales. Utilisez le Design Pattern Singleton au pire.

Je te suggère de transformer ta variable globale en une classe, que tu utilise une seule fois si tu veux.

Par exemple, plutôt qu'avoir:

Code:

---

1 2 3 4 5

int main () { initialiser_truc(); for(int i = 0; i<10; ++i) utiliser_truc(i); vider_truc(); }

---

il vaut mieux avoir ceci:

Code:

---

1 2 3 4 5

int main () { Truc truc(); for(int i = 0; i<10; ++i) truc.utiliser(i); }

---

Ainsi, il n'y a plus de variable globale (je peux avoir deux Truc), et je peux me reposer sur le destructeur de Truc pour garantir le vidage correct (c'est le RAII).

Ou alors tu met factsPhone en static.
En déboguant je te met ma main à coupé que ton factPhone dans initializeFactsPhone n'a pas la même adresse mémoire que celui qui est dans ton Entity.cc.

c'est plutot extern, pour une globale.

static devant une variable "globale" c'est du C-ism, qu'il ne faut pas utiliser en C++, qui garanti que chaque unité de compilation (~chaque .cpp) aura une variable différente (donc une adresse différente)

Mais une globale, c'est souvent une erreur de compilation.

Citation:

---

Envoyé par leternel

c'est plutot extern, pour une globale.

static devant une variable "globale" c'est du C-ism, qu'il ne faut pas utiliser en C++, qui garanti que chaque unité de compilation (~chaque .cpp) aura une variable différente (donc une adresse différente)

Mais une globale, c'est souvent une erreur de compilation.

---

Oui autant pour moi! extern et pas static :scarymov:
Le problème c'est que extern montre un gros défaut de conception ici à mon goût , encapsuler ce std::list serait une bonne solution je trouve

Salut,

Citation:

---

Envoyé par Astraya

Oui autant pour moi! extern et pas static :scarymov:
Le problème c'est que extern montre un gros défaut de conception ici à mon goût , encapsuler ce std::list serait une bonne solution je trouve

---

De toutes manières, la seule idée d'avoir une variable globale susceptible d'être modifiée, quelle que soit la manière dont elle est représentée (en ce, y compris en utilisant l'anti pattern singleton), présente déjà, en soi, un défaut de conception majeur.

Que l'on déclare des constantes comme globales, cela peut se comprendre et se justifier : ca permet d'éviter le recours au valeur magiques, permet l'utilisation de termes plus explicites et facilite la mise à jour si la valeur vient à changer (bien que ce soit très rarement le cas ;) )

Mais on se rend souvent compte que ce que l'on s'apprête à déclarer comme une variable globale n'a aucun sens à être rendue disponible de manière systématique n'importe où: Éventuellement, il y a du sens à la rendre disponible dans un module, et encore... : il est rare de trouver une variable qui devra réellement être rendue accessible à plus de deux ou trois classes différentes. Dés lors, la bonne question à se poser est : pourquoi rendre la variable accessible à l'ensemble des autres classes, au risque de permettre au développeur qui utilise ces autres classes d'utiliser la variable de manière erronée :question: (perso, la réponse est : aucune raison ne peut le jusifier ;) )

Même si je suis globalement d'accord, il y a quelques variables que j'admets de voir en global (et/ou singleton, d'un point de vue design, c'est assez proche). En gros, ce qui est lié à du log (comme std::cout), à des factories, et c'est à peu près tout.

Héhé... Tu auras remarqué que j'ai utilisé les termes "on se rend souvent compte..." et "il est rare de trouver une variable..." :D

Chaque règle a ses exceptions, et nous en avons la preuve une fois de plus ici. Globalement, je vois mal comment représenter les entrées/sorties standards, qui rentrent justement dans la catégories des objets qui risquent effectivement d'être nécessaires depuis strictement n'importe ou, sans passer par une globale quelconque (comprends : quelle qu'en soit la forme ;) ).

Mais je crois que l'on pourrait compter sur les doigts d'une main (allez, peut être des deux mains) les cas où l'utilisation d'une variable globale s'avère strictement justifiée ;)