initialiser un static map

bonjour,

Comme l'explique le titre je voudrais initialiser un static map:

Code:

static std::map<T1,T2> conteneur_map;

Je voudrais qu'il soit vide au d�part.

J'ai trouv� des doc et autres dessus mais je n'ai rien compris...

Merci d'avance

static, ou static?

Citation:

Envoy� par Plomeg

Comme l'explique le titre je voudrais initialiser un static map:

Code:

static std::map<T1,T2> conteneur_map;

Je voudrais qu'il soit vide au d�part.

Il y a static et static. static comment?

variable statique d�clar�e � port�e globale?
variable statique d�clar�e dans une fonction?
membre statique d'une classe?

Citation:

Envoy� par Plomeg

Je voudrais qu'il soit vide au d�part

Le constructeur d'un map fait qu'il est vide au d�part

Si la map est un membre statique d'une classe - elle sera vide par d�faut - mais il me semble que la solution la plus 's�re' serait de cr�er un couple de fonctions qui initialise et de-initialise la partie statique de la classe.
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 class A { static bool ms_bInitialised = false; static std::map<T1,T2> conteneur_map; static void sInit(); static void sClose(); } static void A::sInit() { if(!ms_bInitialised)// à remplacer par un assert si nécessaire { conteneur_map = std::map<T1,T2>(); ms_bInitiliased = true; } } static void A::sClose() { if(ms_bInitialised)// à remplacer par un assert si nécessaire { conteneur_map.clear(); ms_bInitiliased = false; } ; }
Il faudrait donc appeler la fonction sInit avant d'instancer la classe et appeler sClose en fin de programme ou lorsque la classe n'est plus utile.

Citation:
Envoy� par vimes
Si la map est un membre statique d'une classe - elle sera vide par d�faut - mais il me semble que la solution la plus 's�re' serait de cr�er un couple de fonctions qui initialise et de-initialise la partie statique de la classe.
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 class A { static bool ms_bInitialised = false; static std::map<T1,T2> conteneur_map; static void sInit(); static void sClose(); } static void A::sInit() { if(!ms_bInitialised)// à remplacer par un assert si nécessaire { conteneur_map = std::map<T1,T2>(); ms_bInitiliased = true; } } static void A::sClose() { if(!ms_bInitialised)// à remplacer par un assert si nécessaire { conteneur_map.clear(); ms_bInitiliased = false; } ; }
Pourquoi plus s�r?

Tu penses que le constructeur par d�faut et le destructeur de std::map sont bugu�s?

Citation:

Envoy� par vimes

Si la map est un membre statique d'une classe - elle sera vide par d�faut - mais il me semble que la solution la plus 's�re' serait de cr�er un couple de fonctions qui initialise et de-initialise la partie statique de la classe.

Plus s�r : non
plus propre : peut �tre.

Cela a au moins le m�rite de faire (et de demander au d�veloppeur ?) un appel explicite mais cela n'apporte rien de plus.

Citation:

Envoy� par ram_0000

Plus s�r : non
plus propre : peut �tre.

En quoi c'est plus propre?

Citation:

Envoy� par ram_0000

Cela a au moins le m�rite de faire (et de demander au d�veloppeur ?) un appel explicite mais cela n'apporte rien de plus.

En gros on cr�� une contrainte sur l'utilisation de la map; pourquoi?

Citation:

Envoy� par ram_0000

Plus s�r : non
plus propre : peut �tre.
Cela a au moins le m�rite de faire (et de demander au d�veloppeur ?) un appel explicite mais cela n'apporte rien de plus.

Tu as raison : en fait, je voulais dire que c'�tait plus s�r en terme de developpement.

d�sol� pour la pr�cision mais c'est bien static de classe, donc � initialiser � l'ext�rieur sinon erreur de linker (c'est mon cas). Il faudrait donc faire quelque chose comme:

Code:

std::map<T1,T2> ClasseProprietaire::conteneur_map = "quelque chose";//en dehors de la classe

Enfin je crois. Je pense qu'il faudrait cr�er un map du m�me type et faire �gal (mais j'ai tester et �a ne veut pas non plus).

variable static membre

Citation:

Envoy� par Plomeg

d�sol� pour la pr�cision mais c'est bien static de classe, donc � initialiser � l'ext�rieur sinon erreur de linker (c'est mon cas). Il faudrait donc faire quelque chose comme:

Code:

std::map<T1,T2> ClasseProprietaire::conteneur_map = "quelque chose";//en dehors de la classe

Enfin je crois. Je pense qu'il faudrait cr�er un map du m�me type et faire �gal (mais j'ai tester et �a ne veut pas non plus).

Non, il suffit de la d�finir � l'ext�rieur de la classe (une seule fois dans le programme) :
Code:

1 2 3 // dans ClasseProprietaire.cpp : std::map<T1,T2> ClasseProprietaire::conteneur_map; // initialisation par défaut (vide)
ou bien
Code:

1 2 std::map<T1,T2> ClasseProprietaire::conteneur_map = une_autre_map; // initialisation par recopie
ou
Code:

1 2 std::map<T1,T2> ClasseProprietaire::conteneur_map (debut, fin); // initialisation avec la range [debut, fin)

trop simple pour y penser^^. Je ne sais pas pourquoi mais en mettant la d�finition juste apr�s la classe, le compilo consid�rait �a comme une d�claration. En fait il suffisait de le d�placer dans le .cpp mais je ne sais pas pourquoi. En attendant : :resolu:

Citation:

Envoy� par Plomeg

trop simple pour y penser^^. Je ne sais pas pourquoi mais en mettant la d�finition juste apr�s la classe, le compilo consid�rait �a comme une d�claration.

Bien s�r, par d�finition toute d�finition est aussi une d�claration.

Blague � part (je vois ce que tu veux dire!), je crois que tu te trompes.

Citation:

Envoy� par Plomeg

En fait il suffisait de le d�placer dans le .cpp mais je ne sais pas pourquoi. En attendant : :resolu:

Le compilateur proprement dit[1] ne fait pas la diff�rence : il ne voit qu'une s�rie de d�clarations, il n'a aucun id�e si tu les as mises dans un en-t�te ou dans un .cpp.

La diff�rence, c'est si tu inclus un en-t�te � plusieurs endroits, son contenu se trouve dupliqu�.

Le pr�processeur est juste �a : un outil pour dupliquer des d�clarations de fa�on ad�quate.

[1] techniquement : phase 7 de la traduction,

Citation:

Envoy� par corrector

En quoi c'est plus propre?

En gros on cr�� une contrainte sur l'utilisation de la map; pourquoi?

Parce que je n'aime faire le nettoyage de mani�re implicite par le destructeur. J'aime bien le faire de mani�re explicite. Peut �tre une habitude que j'ai prise du C.

Bon, c'est sur que dans ce cas, il y a la m�thode map.clear() qui fait la m�me chose (et qui est certainement appel�e par le destructeur)

Citation:

Envoy� par ram_0000

Parce que je n'aime faire le nettoyage de mani�re implicite par le destructeur. J'aime bien le faire de mani�re explicite.

Oui, mais pourquoi?

Citation:

Envoy� par ram_0000

Peut �tre une habitude que j'ai prise du C.

Est-ce encore pertinent en C++?

Citation:

Envoy� par ram_0000

Bon, c'est sur que dans ce cas, il y a la m�thode map.clear() qui fait la m�me chose (et qui est certainement appel�e par le destructeur)

Peut-�tre, mais pas forc�ment : clear() a une post-condition (exprim�e en terme de *this), le destructeur non, par d�finition.

Je ne suis pas s�r que je vais �tre clair, mais sInit/sClose permet aussi d'encapsuler la logique de la classe de mani�re plus visible. Par exemple, si tu avais une map de pointeurs plut�t qu'une map d'objets,seuls l'impl�mentation de sInit et de sClose permettrait de traiter les deux cas suivant :
- ta classe est propri�taire du contenu de la map et doit d�sallouer le contenu avant de sortir
- ta classe n'est pas propri�taire du contenu de la map et elle ne fait que vider la map.
Ce sont des garde-fous pas forc�ment n�cessaires mais qui rendent le code plus maintenable � mon avis.

Citation:

Envoy� par vimes

Par exemple, si tu avais une map de pointeurs plut�t qu'une map d'objets,seuls l'impl�mentation de sInit et de sClose permettrait de traiter les deux cas suivant :
- ta classe est propri�taire du contenu de la map et doit d�sallouer le contenu avant de sortir

Tu peux faire ce nettoyage dans le destructeur d'un (autre) objet statique, justement.

(Tu peux aussi utiliser boost dans ce cas, mais je suppose que c'est seulement un exemple.)