Gérer des constantes

Version imprimable

27/01/2006, 16h36
oldfox

Gérer des constantes

J'ai besoin de constantes dans un programme, et j'aimerais avoir pour une fois quelque chose de plus propre que des const déclaré dans un coin, et en extern partout ailleurs....

Quelle technique utiliser pour faire cela bien?

Est-il possible par exemple de créer une classe Constante:: contenant toutes ces constantes et accessible de tout le programme?
Est-ce qu'il est obligatoire d'instancier cette classe pour l'utiliser ou peux on accéder aux attribut de nimporte ou en fesant simplement Constante::MaxTaille ??

Merci pour vos conseils!
27/01/2006, 16h57
xxiemeciel

Salut,

Tu peux utiliser un namespace

http://c.developpez.com/faq/cpp/?page=namespace

XXiemeciel
28/01/2006, 00h14
Clad3

Hum, regarde du coté des singletons ( je n'ai pas de lien sous la main, mais google fera l'affaire ) .
28/01/2006, 08h58
PRomu@ld

Citation:

Est-ce qu'il est obligatoire d'instancier cette classe pour l'utiliser ou peux on accéder aux attribut de nimporte ou en fesant simplement Constante::MaxTaille ??

Il faut pour cela utiliser des champs static
28/01/2006, 09h04
oldfox

J'ai essayé avec les champs statics comme dans la FAQ mais ca refuse de linker quand j'appel directement Constante::maconstante

Je me rends pas compte de se que ca donne avec les namespace faut que je test ca!
28/01/2006, 09h09
PRomu@ld

Citation:

J'ai essayé avec les champs statics comme dans la FAQ mais ca refuse de linker quand j'appel directement Constante::maconstante

Oulà, envoie ton code parce que ce n'est pas très normal tout ça (en plus une erreur de linker ...)

Autant pour moi ca marche parfaitement j'avais du trop boire de ricard... :)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 #ifndef __Constantes_h__ #define __Constantes_h__ class Constantes{ public: static const double TOL; }; const double Constantes::TOL = 0.00000001; #endif //__Constantes_h__
J'aime bien cette approche vu qu'elle marche :) Avez vous des idées sur les avantages/inconveignants par la rapport a un namespace?

Salut,
Pourquoi utiliser un classe avec seulement des donnée static?
j'aurai plutot tendance a utilier un namespace
Code:

1 2 3 4 5 6 7 8 9 10 11 12 // un fichier mes_constante.h #ifndef _MES_CONSTANTES_H_ #define _MES_CONSTANTES_H_ namespace MesConstantes { const int UN_INT = 1; const std::string UN_STRING = "toto"; ... } #endif
puis dans le code tu y accede

Code:

MesConstantes::UN_INT /* par exemple */

Citation:
Envoyé par oldfox
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 #ifndef __Constantes_h__ #define __Constantes_h__ class Constantes{ public: static const double TOL; }; const double Constantes::TOL = 0.00000001; #endif //__Constantes_h__
J'aime bien cette approche vu qu'elle marche :)
Bin, non, telle qu'écrite, elle ne marche pas...
La définition de la constante doit se trouver dans un fichier .cpp, et non pas dans un .h. Comme toujours, le principe est le même : On peut avoir plusieurs déclarations, mais une seule définition.

Citation:

Envoyé par oldfox

Avez vous des idées sur les avantages/inconveignants par la rapport a un namespace?

Le but dans les deux cas est de classer la constante (d'ailleurs, nommer ça constante n'a pas grand intérêt, car ça ne classe rien. Par contre, les séparer en ConstantePhysiques, TauxDeChangeVersEuro... a de l'intérêt).

L'utilisation d'un namespace offre l'avantage d'être extensible. Si dans un autre fichier, tu dois définir une autre constante qui appartient au même groupe logique que celles déjà défini, tu peux réouvrir le namespace. En outre, avec les jeu des using, tu peux éviter localement de spécifier le nom complètement qualifié quand tu doit dans un endroit traiter beaucoups de constantes de la même catégorie.

L'utilisation de classe pour ça en C++ est une relique de l'époque où il n'y avait pas de namespace. D'autre langages utilisent une classe car il leur manque la possibilité de définir une constante autrement.

28/01/2006, 11h30
Blowih

Citation:

L'utilisation d'un namespace offre l'avantage d'être extensible. Si dans un autre fichier, tu dois définir une autre constante qui appartient au même groupe logique que celles déjà défini, tu peux réouvrir le namespace. En outre, avec les jeu des using, tu peux éviter localement de spécifier le nom complètement qualifié quand tu doit dans un endroit traiter beaucoups de constantes de la même catégorie.

L'utilisation de classe pour ça en C++ est une relique de l'époque où il n'y avait pas de namespace. D'autre langages utilisent une classe car il leur manque la possibilité de définir une constante autrement.

+1 :D
28/01/2006, 14h06
oldfox

Citation:

Envoyé par JolyLoic

Bin, non, telle qu'écrite, elle ne marche pas...
La définition de la constante doit se trouver dans un fichier .cpp, et non pas dans un .h. Comme toujours, le principe est le même : On peut avoir plusieurs déclarations, mais une seule définition.

Sisi ca marchait :) J'ai mis dans un .cpp depuis.

Bon je vais faire ca sous forme de namespace ca a l'air plus simple en effet. Merci ;)
28/01/2006, 14h09
Blowih

Citation:

Bon je vais faire ca sous forme de namespace ca a l'air plus simple en effet.

je dirais plus adapté :wink:

(pense a un petit résolu si c'est bon )

Ciao

Ben
28/01/2006, 14h10
oldfox

C'était pas vraiment un probleme: juste une question ouverte :)
28/01/2006, 23h05
MatRem

Personnelement je pense que pour un projet objet (un projet c++ en fait parti), l'utilisation de variables globales et donc de constantes de namespace n'est pas trés pertinent.

A mon avis, quasiment tout le temps, une constante peut être vu comme faisant partit des caractéristiques d'une certaine classe d'objet. Et donc elle peut être définit comme variable de classe.

En c++ cela donne une variable static const.

Bon c'est sur, certains diront que cela ne changera pas grand chose,.
Cependant dans le vision Objet du projet c'est quand même plus "propre" (:P).
28/01/2006, 23h26
oldfox

Dans ce cas précis ce sont des classes pour du calcul mathématique (donc vecteurs, matrices etc...), qui doivent donc partager certaines constantes. Je sais pas trop comment organiser ca autrement pour k'il n'y ai besoin ke de mettre la constante a un seul endroit.
28/01/2006, 23h31
MatRem

C'est quoi par exemple la/les constantes et la/les classes mises en jeu?
29/01/2006, 09h54
Jean-Marc.Bourguet

Citation:

Envoyé par oldfox

Citation:

Envoyé par JolyLoic

Bin, non, telle qu'écrite, elle ne marche pas...
La définition de la constante doit se trouver dans un fichier .cpp, et non pas dans un .h. Comme toujours, le principe est le même : On peut avoir plusieurs déclarations, mais une seule définition.

Sisi ca marchait :) J'ai mis dans un .cpp depuis.

Ce que tu as fait n'est pas clair pour moi. Si tu inclus ton entête tel quel dans plus d'un cpp, tu vas avoir des problèmes.
29/01/2006, 09h59
Jean-Marc.Bourguet
Citation:

Envoyé par JolyLoic

L'utilisation de classe pour ça en C++ est une relique de l'époque où il n'y avait pas de namespace. D'autre langages utilisent une classe car il leur manque la possibilité de définir une constante autrement.

Je connais trois intérêts à faire une classe avec uniquement des membres statiques plutôt qu'un namespace:
- une classe est fermée, donc on est sûr de ce qu'il y a dedans
- une classe peut être un paramètre template
- une classe peut être un template
29/01/2006, 10h10
Jean-Marc.Bourguet

Citation:

Envoyé par MatRem

Personnelement je pense que pour un projet objet (un projet c++ en fait parti), l'utilisation de variables globales et donc de constantes de namespace n'est pas trés pertinent.

Un des intérêt du C++, c'est qu'il n'oblige pas à être objet (en admettant qu'on soit d'accord sur ce qu'on appelle être objet, ce dont je ne suis pas sûr). Faire comme en Effeil et hériter d'une classe pour pouvoir utiliser sin et cos me semble être extrêmement artificiel et relever de la technique "si le seul outil qu'on a est un marteau, on n'utilise que des clous". C++ a d'autres outils de structuration que la classe, pourquoi refuser de les utiliser?

Citation:

A mon avis, quasiment tout le temps, une constante peut être vu comme faisant partit des caractéristiques d'une certaine classe d'objet. Et donc elle peut être définit comme variable de classe.

En c++ cela donne une variable static const.

Bon c'est sur, certains diront que cela ne changera pas grand chose,.
Cependant dans le vision Objet du projet c'est quand même plus "propre" (:P).

Il faudrait que tu donnes d'autres raisons que "ca ne correspond pas à ma vision d'Objet" pour me convaincre.
29/01/2006, 13h15
JolyLoic
Citation:
Envoyé par Jean-Marc.Bourguet

Citation:

Envoyé par JolyLoic

L'utilisation de classe pour ça en C++ est une relique de l'époque où il n'y avait pas de namespace. D'autre langages utilisent une classe car il leur manque la possibilité de définir une constante autrement.

Je connait trois intérêts à faire une classe avec uniquement des membres statiques plutôt qu'un namespace:
une classe est fermée, donc on est sûr de ce qu'il y a dedans
une classe peut être un paramètre template
une classe peut être un template
Je suis d'accord avec ta vision, j'ai parlé trop vite.
29/01/2006, 18h10
MatRem

Citation:

Un des intérêt du C++, c'est qu'il n'oblige pas à être objet (en admettant qu'on soit d'accord sur ce qu'on appelle être objet, ce dont je ne suis pas sûr). Faire comme en Effeil et hériter d'une classe pour pouvoir utiliser sin et cos me semble être extrêmement artificiel et relever de la technique "si le seul outil qu'on a est un marteau, on n'utilise que des clous". C++ a d'autres outils de structuration que la classe, pourquoi refuser de les utiliser?

Tout simplement, C++ a été créé par dessus le C. Il est donc possible de faire du C avec le C++.
Le C++ n'est donc pas un langage purement Objet (comme le Java par exemple), ce qui permet de mélanger les concepts Objet avec d'autre concepts hérité du C.
Et à mon avis (et c'est même sur si on regarde le java) il est possible de faire un projet basé seulement sur des concepts objets.
De tout façon je n'expose que mon point de vue de la chose (je ne dis pas que les concepts fonctionnels du C sont moins bien que la POO).
Mais personnelement je ne mélange pas les deux, car c'est pour moi la meilleur façon de détruire la "propreté" de ce que permettent les langages purement objets.

voilà voilà, je sait pas si tu comprends mon point de vue :roll:
29/01/2006, 20h39
Jean-Marc.Bourguet

Citation:

Envoyé par MatRem

Mais personnelement je ne mélange pas les deux, car c'est pour moi la meilleur façon de détruire la "propreté" de ce que permettent les langages purement objets.

Tu peux m'expliquer ce que sont les "langages purement objets" et quel est leur "propreté" particulière?
29/01/2006, 22h20
MatRem
1)

Citation:

Tu peux m'expliquer ce que sont les "langages purement objets"

Oui.

Citation:

Langage objet:
Mode de programmation dans lequel le code source du programme est la modélisation des entités du monde réel ou d'entités logiques par des objets s'échangeant des services par messages. Ils possèdent des caractéristiques qui définissent leur état, et des comportements qui définissent leur réaction aux problèmes.

Par langage purement objet, j'entends: des langages qui n'ont que le comportement ci dessus.

Donc c++ n'est pas à mon sens un langage purement objet. Cependant il possède lla plupart de leur caractéristiques. Il permet donc de réaliser des projets à qui mixent les concepts Objets à d'autres.

2)

Citation:

quel est leur "propreté" particulière

Il permette par leur façon d'organiser le code source:
- - d'éviter les erreur
  - d'être trés lisible
  - d'être facilement reutilisable
  - d'être facile à comprendre (puisque comparable au monde réel)
  - ... (je crois qu'il ya beaucoup de site qui traite de l'apport positif de l'objet)
En utilisant les concepts proposés par le C (concepts procédurales, variables globales, ...) le codes sources sera moins "propre" (cette fois ci tu sait ce que je veux dire par là,) qu'en utilisant seulement ceux du C++.
Et mélanger les deux, à mon avis, ça n'aide pas à réaliser une bonne étude de la partie Objet.

Encore une fois je le répète, tout ce que je dis se rapporte à ma façon de programmer.
30/01/2006, 01h19
Luc Hermitte
Citation:
Envoyé par MatRem

2)

Citation:

quel est leur "propreté" particulière

Il permette par leur façon d'organiser le code source:

a- d'éviter les erreur
b- d'être trés lisible
c- d'être facilement reutilisable
d- d'être facile à comprendre (puisque comparable au monde réel)
e- ... (je crois qu'il ya beaucoup de site qui traite de l'apport positif de l'objet)

f- En utilisant les concepts proposés par le C (concepts procédurales, variables globales, ...) le codes sources sera moins "propre" (cette fois ci tu sait ce que je veux dire par là,) qu'en utilisant seulement ceux du C++.
Et mélanger les deux, à mon avis, ça n'aide pas à réaliser une bonne étude de la partie Objet.
b-

Code:

c.setX( a.getY() + b.getZ());

c- Cela me rapelle ces mauvais arguments marketings associés aux objets qui vendaient que tout serait réutilisable. Le genre de travers qui font hériter (publiquement) les listes triées des simples listes.

d- Puisqu'on en parle. Je ressors l'autre exemple plus classique/récurrent sur le LSP à savoir : "les carrés ne sont pas des rectangles" -- contre-exemple classique comme quoi avec les objets on ne peut toujours modéliser immédiatement nos préconceptions.

e- Google est-il vraiment notre ami ?

f- Attention à un autre piège (non évoqué mais qui arrive vite quand on oppose variables globales au monde OO) : Ce n'est pas parce qu'un singleton est un objet que c'est foncièrement plus propre que des variables globales -- ne parlons même pas du singleton façade (qui regroupe trop de choses différentes) et qui est hérité entre deux sous composants.

Ne pas oublier que l'objet n'est pas un but en soit.

Ces disgressions me rappellent, qu'il faudrait que j'avance dans ma lecture de Multiparadigm design in C++ de coplien.