Discussion :

[oodini]

Hello,

Je fais un programme avec une classe qui contient un ensembles d'options globales, qui n'aura qu'une seule instance, et qui devra pouvoir ête consultée par tout le monde.

Y a-t-il une manière plus propre de faire cela, sans déclarer un pointeur global vers cette classe, puis de lui affecter uen instance en cours d'exécution du programme ?

Merci.

[jomeo]

Il faut que tu crées une classe et que tu y définisses des méthodes statiques et publiques.

Ainsi tu pourras appeler ces méthodes en faisant un simple nomClasse::maMethode(...).

Pour que ta classe soit "visible" de partout, il suffira d'inclure le fichier d'en-tête partout :-)

Edit : cherche aussi comment concevoir un "Singleton" en C++. il s'agit justement d'une classe qui vise à n'être instanciée qu'une seule fois. Je crois qu'il y a pas mal de petites choses à définir (constructeurs, opérateurs, etc.) pour qu'un Singleton soit correct. J'ai eu des cours en java là dessus et c'était sacrément tordu.

Bon courage !

[jln13]

Peut etre que ceci répond a ta question :
http://support.microsoft.com/kb/460664/fr

[Ksempac]

qui n'aura qu'une seule instance, et qui devra pouvoir ête consultée par tout le monde.

Renseigne toi sur le Singleton, une design pattern qui a ses caracteristiques.

Cela dit, cette histoire de classes qui contient des options globales, ca me semble un affreux bidouillage. Que veux tu faire exactement ?

[oodini]

Il faut que tu crées une classe et que tu y définisses des méthodes statiques et publiques.

Ainsi tu pourras appeler ces méthodes en faisant un simple nomClasse::maMethode(...).

Pour que ta classe soit "visible" de partout, il suffira d'inclure le fichier d'en-tête partout :-)!

Ca m'a l'air d'être la bonne méthode.

Merci.

[oodini]

Renseigne toi sur le Singleton, une design pattern qui a ses caracteristiques.

Je crois savoir que son seul intérêt, c'est de s'assurer qu'on ne peut avoir qu'une seule instance ?
Dans ma cas, ce n'est pas impératif de poser cette contrainte. Je maîtrise totalement mon code, et personne d'autre que moi ne risque d'instancier une seconde fois la classe. :-)
Mon principal problème était la visibilité.

Cela dit, cette histoire de classes qui contient des options globales, ca me semble un affreux bidouillage. Que veux tu faire exactement ?

Pour simplifier, disons que j'ai un main() (bien qu'en fait, je fasse un plug-in d'une autre appli.. mais bon..), et que je définis l'instance d'un noeud qui contiendra un ensemble d'informations.

Viennent ensuite toute une série de classes, dont des instances sont définies dans le main(), qui devront exploiter les données présentes dans cette instance de classe d'options.

Une solution serait de passer en paramètre à chacun des constructeurs de toutes ces classes une références vers l'objeyt contenant les options, mais ça me paraît un peu stupide de me cogner un paramètre supplémentaire pour chacune des classes.

[koala01]

Salut,

Je crois savoir que son seul intérêt, c'est de s'assurer qu'on ne peut avoir qu'une seule instance ?
Dans ma cas, ce n'est pas impératif de poser cette contrainte. Je maîtrise totalement mon code, et personne d'autre que moi ne risque d'instancier une seconde fois la classe. :-)
Mon principal problème était la visibilité.

...jusqu'au jour où quelqu'un viendra te donner un coup de main et, parce qu'il n'aura pas compris l'idée de ta classe, essayera d'en implémenter une seconde...

S'il est vrai que le patern singleton a, entre autre, l'avantage de ne pouvoir etre instancié qu'une fois, il a aussi l'avantage de pouvoir partager une instance unique partout

Pour simplifier, disons que j'ai un main() (bien qu'en fait, je fasse un plug-in d'une autre appli.. mais bon..), et que je définis l'instance d'un noeud qui contiendra un ensemble d'informations.

Viennent ensuite toute une série de classes, dont des instances sont définies dans le main(), qui devront exploiter les données présentes dans cette instance de classe d'options.

Une solution serait de passer en paramètre à chacun des constructeurs de toutes ces classes une références vers l'objeyt contenant les options, mais ça me paraît un peu stupide de me cogner un paramètre supplémentaire pour chacune des classes.

Pourquoi à toutes les fonctions

Tu peux très bien déclarer une référence ou un pointeur vers ta classe conteneur comme membre de tes autres classes, et te contenter de le passer en parametre au constructeur...

Le conteneur étant alors membre de chacune de tes classes, il sera aisé d'y accéder au sein meme des classes

[oodini]

S'il est vrai que le patern singleton a, entre autre, l'avantage de ne pouvoir etre instancié qu'une fois, il a aussi l'avantage de pouvoir partager une instance unique partout

Je ne savais pas ça.
Je vais donc essayer le singleton. :-)

Tu peux très bien déclarer une référence ou un pointeur vers ta classe conteneur comme membre de tes autres classes, et te contenter de le passer en parametre au constructeur...

C'est ce que je voulais éviter.

[koala01]

C'est ce que je voulais éviter.

Tu as surement des raisons valables... mais penses quand meme qu'un pointeur, ca ne prend que quelques octets en mémoire...(32 bits, sur mon athlon XP)

Si la seule raison que tu aies est celle d'essayer de préserver la mémoire, ca peut valoir la peine de reconsidérer la question

[koala01]

Ceci dit, comprenons nous bien sur la valeur du terme "partout" que j'ai utilisé deux messages plus haut...

Il s'agit bien des unités de traductions dans lesquelles, par jeu d'inclusions interposées, il y a non seulement la délcaration de ta classe singleton, mais aussi la définition d'une instance de celui-ci

[NewbiZ]

Le débat tout statique contre singleton est infini.

Ce qu'on peut en retirer, c'est que le singleton offre un avantage important par rapport au tout statique : il fournit un point d'entrée unique ( son constructeur ) ce qui te permet d'avoir une initialisation sure.