validite d'une static global dans une classe

Bonjour,

J'ai une classe CMaClasse, definit dans un .h et .cpp(classique), sauf que dans mon cpp j'ai en haut:

Code:

---

static typeList* uneListe = NULL;

---

Tout fonctionne correctement, la liste est bien initialise une seule fois dans le contructeur et bien utilise.
Maintenant j'ai un doute au niveau de la memoire.

J'utilise ma classe ainsi:

Code:

---

1 2 3 4 5 6 7

// Par exemple dans un main: CMaClasse* p1 = new CMaClasse(); CMaClasse* p2 = new CMaClasse(); // <-- uneListe != NULL delete p1; CMaClasse* p3 = new CMaClasse(); // <-- uneListe != NULL delete p2; delete p3;

---

La je pense que uneListe est creer une seule fois.

Mais la:

Code:

---

1 2 3 4 5 6 7 8 9

// Par exemple dans un main: CMaClasse* p1 = new CMaClasse(); CMaClasse* p2 = new CMaClasse(); // <-- uneListe != NULL delete p1; delete p2; CMaClasse* p3 = new CMaClasse(); // <-- ici delete p3;

---

Lorsque je cree p3, est-ce que uneListe est cense etre plein ou vide. Dans mon cas j'ai bien uneListe != NULL, mais pourtant j'ai supprimer toutes les instances de la classe(p1 et p2).
Est-ce que c'est normal?

PS: il est possible que la conception soit mauvaise, mais ce code n'est pas a moi, je dois le reprendre et j'aimerai deja comprendre ce qu'il fait, avant de modifier.

Une variable statique n'appartient à aucune instance de la classe, donc sa durée de vie est supérieure.

Je ne peux pas dire grand-chose de plus sans le code du destructeur de CMaClasse...

Ok, en fait c'est un brin complique car ce n'est pas detruit dans le destructeur.
Enfin pour faire simple, c'est une liste de buffer, on les alloue au fur et a mesure, et plutot que de les desallouer quand on en a plus besoin, on les laisse pour les reutiliser plus tard sans passer par la case malloc(), (tout ca fait a l'aide d'un compteur...).

Mais bon je pense que tu a repondu a ma question:

Citation:

---

Une variable statique n'appartient à aucune instance de la classe, donc sa durée de vie est supérieure.

---

du coup si je comprend bien ces variables sont directement creer au lancement du prog, et pas a la (1ere) creation de la classe?

Pour ta dernière question, je ne sais pas. Je ne sais pas ce que la norme permet, ni comment c'est implémenté.

Mais ici, comme la variable est un pointeur, elle est initialisée par Autre Chose.

Et cet AutreChose pourrait bien être le constructeur de la classe, qui ferait un if(uneListe == NULL) uneListe = new typeList();...

Citation:

---

Envoyé par kacedda

du coup si je comprend bien ces variables sont directement creer au lancement du prog, et pas a la (1ere) creation de la classe?

---

Pas exactement. En fait, les variables statiques sont vraiment crées lorsqu'elle sont initialisées. Dans ton exemple, c'est la ligne

Code:

---

static typeList* uneListe = NULL;

---

qui créé véritablement cette variable. Elle sera donc créée lorsque l'exécution passera la première fois à cet endroit. Elle sera alors stockée dans une partie de la mémoire dédiée aux variables statiques et n'en bougera pas jusqu'à la fin de l'exécution de l'appli.

[edit]houla oui, je n'avais pas vu que c'était un pointeur... ça me parait dangereux ça :S

Pour moi, une variable statique pointeur est moins dangereuse qu'une variable statique avec un constructeur: On contrôle mieux son le moment de son initialisation, ce qui peut être vital en cas de dépendance à un autre objet.

Ta variable est dans l'unité de compilation, le .cpp. C'est généralement des choses qu'on voit beaucoup quand on programme en C ou dans du vieux code C++. Mais j'ai tendance à voire ça comme une mauvaise habitude.

Pourquoi ne pas l'avoir rentrée dans la définition de la classe ?

Oups, m'ai mal exprimé:aie:
en fait je voulai parler de maniere generale, donc ici plutot l'instance du pointeur(les 4 octets de l'adresse je crois).
Sinon oui la liste est bien initialisé comme dis Médinoc(enfin pas loin).

Donc sinon... je suppose que ces variables (pointeur ou pas) sont alloués au lancement du programme.

[Edit:NiamorH] c'est pas mon code, et pour etre honnete je sais pas encore ce qui est le mieux, j'imagine qu'il y a quand meme une raison derriere tout ca

Même si elle était dans la classe, ça ne change rien au fait qu'elle soit statique.

ben si, non?
car lorsque je supprime toutes mes instances je repars a zero
alors qu'en global non

Citation:

---

Envoyé par kacedda

Donc sinon... je suppose que ces variables (pointeur ou pas) sont alloués au lancement du programme.

---

Non, elle sont allouées lors de leur initialisation.

Citation:

---

Envoyé par kacedda

ben si, non?
car lorsque je supprime toutes mes instances je repars a zero
alors qu'en global non

---

Heu il n'y a rien d'automatique non. C'est à toi de farie ça toi même.

C'est juste que la rentrer dans la classe permet de ne pas polluer l'espace de nom global.

Il est possible de faire ça manuellement avec un compteur qu'on incrémente dans le constructeur et qu'on décrémente dans le destructeur (un peu comme un compteur de références), mais le C++ ne le fait pas à ta place, car tu n'as pas forcément envie de faire ça...

Citation:

---

Envoyé par r0d

Non, elle sont allouées lors de leur initialisation.

---

Me suis encore mal exprimé, en fait je voulai dire que les 4 octet de l'adresse sont attribué, le &uneListe, apres je suis d'accord ca pointe nulle part jusqu'a l'initialisation.

Et sinon j'ai du louper un coche.
Si j'ai ca:

Code:

---

1 2 3 4 5 6 7

//.h CMaClasse{ static unType uneVariable; //.cpp unType CMaClasse::uneVariable = null;//ou 0... }

---

Dans mon main:

Code:

---

1 2 3 4 5 6

CMaClasse* p1 = new CMaClasse(); CMaClasse* p2 = new CMaClasse(); delete p1; delete p2; // <-- ici uneVariable n'existe plus? ou existe toujours?

---

La uneVariable ne doit plus exister puisque c'est une variable membre et que j'ai supprimer toutes les instances.

Alors que si c'etait une variable globale non membre, la uneVariable existerai(enfin si j'ai bien compris)

Fais le test, tu verras :

Code:

---

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

class Test {   static int i; };   int Test::i = 20;     int main() { Test::i = 32; std::cout << Test::i; }

---

Pas besoin d'instances pour que la variable existe bien...

Citation:

---

Envoyé par kacedda

Me suis encore mal exprimé, en fait je voulai dire que les 4 octet de l'adresse sont attribué, le &uneListe, apres je suis d'accord ca pointe nulle part jusqu'a l'initialisation.

---

Non ces octets ne sont pas attribués tant que la variable n'a pas été initialisée. Pour être précis, la variable n'existe pas tant qu'elle n'est pas initialisée. Pour t'en convaincre, fais le test suivant: tu initialise ta variable statique après un bout de code qui l'utilise. L'erreur obtenue n'est pas une seg fault, mais bel et bien une erreur de link à la compilation.

En fait, les variables statiques ne sont finalement que des variables globales à l'application. Et ce que j'appelle ici 'initialisation' (je ne trouve pas mieux) n'est en fait que la déclaration.

Ok pour NiamorH, et j'ai fait le test de r0d, effectivement ca compile pas.
Donc apparament me suis un peu plante, bon, au moins j'y voit un peu plus clair et je comprend mieux le code...
Ok merci à tous pour les explications!

...mais?
Mais donc si je comprend bien il n'y a aucune différence entre la déclarer en global ou en membre? Mis a part le fait qu'une variable membre est accessible de l'exterieur, enfin c'est deja une grosse difference.

Oui, la différence n'est finalement qu'une histoire de portée et d'accessibilité (public, private ...).

Mais c'est déjà une grosse différence ;)

:D

:aie:vais plus faire que des membres static pour gagner en memoire:aie:

Thanks all:king:

Il n'y a aucune différence au niveau "runtime" (à l'execution quoi). La mémoire de la variable est allouée dès que l'executatable (ou la librairie) est chargée, initialisée avant le "main", désinitialisée après le "main". L'ordre de désinitialisation est toujours l'ordre inverse de l'initialisation, mais rien ne permet de contrôler cet ordre:

Code:

---

1 2 3

static const std::string toto = "toto"; static const std::string tata = "tata"; // peut très bien être initialisé avant toto (mais dans ce cas sera désinitialisé après).

---

Il y a quand même des différences "sémantiques" notoires...

statique dans le source: variable uniquement liée à l'unité de compilation, invisible hors de celle-ci.

statique privée dans la déclaration de classe: variable liée à la classe, donc visible par celle-ci mais aussi par toutes les classes amies.

statique protégée dans la déclaration de classe: variable liée à la classe et visible par celle-ci, ses amies et les classes qui en héritent

statique publique dans la déclaration de classe: variable globale accessible par tout le monde.

Citation:

---

Envoyé par nicroman

statique dans le source: variable uniquement liée à l'unité de compilation, invisible hors de celle-ci.

---

Même avec le mot clef extern ?

Pour contrôler l'ordre de désinitialisation, j'ai le souvenir qu'Alexandrescu avait donné un truc avec l'utilisation de la fonction atexit. Il faudrait que je regarde.

Citation:

---

Envoyé par NiamorH

Même avec le mot clef extern ?

---

On parle de déclaration....

Dans un source, si il ya "extern machin trucmuche", ca veut dire que trucmuche doit être importé d'une autre unité de compilation lors du "link".

Quand au "static" global... il suffit de faire le test dans un header, inclut dans plusieurs sources...

Code:

---

1 2	static const std::string test="test de chaine";

---

Chaque source aura sa propre instance de "test".

Citation:

---

Envoyé par r0d

Non, elle sont allouées lors de leur initialisation.

---

une variable globale static est initialisé au lancement du programme non?

Citation:

---

Envoyé par nicroman

Quand au "static" global... il suffit de faire le test dans un header, inclut dans plusieurs sources...

Code:

---

1 2	static const std::string test="test de chaine";

---

Chaque source aura sa propre instance de "test".

---

Oui ! Je me souviens en avoir déjà fait les frais...

Mon cas était un peu différent donc je le poste ici au cas où quelqu'un rencontre le probleme à nouveau.

J'avais implémenté un simple singleton monothread de la sorte :

Code:

---

1 2 3 4 5 6

MonSingleton & MonSingleton::Instance() { static MonSingleton inst; return inst; }

---

Jusque là pas de soucis, mais j'avais par erreur, inliné la méthode. Résultat : en débug tout allait bien mais en Release, comme mon singleton était appellé à des endroits différents, les instances étaient différentes à chaque endroit, plantage à la fermeture du programme évidement. J'ai mis longtemps avant de trouver que l'erreur venait de là.

Oui, sinon on aurait du mal avec les traits.

(réponse au message de NiamorH avec le Test::i & compagnie)