Variables globales dans une classe

Bonjour,

Et elle n'est pas banal c'est question :-), elle est ridicule mais là j'ai gros trou de mémoire.

Actuellement j'ai pas mal de constantes dans mes classes. Cependant elles sont globales et non pas uniquement liées à la classe. Mais en faisant les define dans la classe.
Comment puis-je utiliser des constantes pour quels ne soit visible que par la classe ou en faisant CClass::Constante ?

Merci d'avance et encore désolé pour cette question

Bye


[Titre modifié par Loulou24, merci d'utiliser des titres explicites]

dans le header :

Code:

---

1 2 3 4 5

class maths { static const double pi; };

---

Dans l'implementation

Code:

---

1 2	const double maths::pi=3.14159; // oui c'est un peu court.

---

salut

voir post pour constantes globales dans une classe ou un namespace

petite precision d'ecriture par convention les constantes sont ecrites entierement en majuscules :wink: juste un detail mais respecter par beaucoup de developpeurs par soucis de lisibilité

Citation:

---

Envoyé par star_light

petite precision d'ecriture par convention les constantes sont ecrites entierement en majuscules :wink: juste un detail mais respecter par beaucoup de developpeurs par soucis de lisibilité

---

pas toujours, car on peut les confondre avec les macros.
en particulier, si les constantes sont regroupées dans une classe ou un namespace Constantes (par exemple) il n'y aura pas d'ambiguité avec les variables donc on peut les mettre en minuscules. là où il peut y avoir ambiguité et ou les majuscules ou une autre convention s'impose c'est dans le cas de l'emploi de "extern". dans ce cas la convention employée est le seul moyen de différencier tout de suite les constantes des variables (surtout quand celui qui lit le code n'est pas celui qui l'a écrit).

:P

Citation:

---

Envoyé par Gandalf

Code:

---

1 2	const double maths::pi=3.14159; // oui c'est un peu court.

---

---

Code:

---

1 2 3 4

const double maths::pi=4*atan(1.0); // là c'est moins court // const double maths::pi=2*acos(1.0); // ...

---

:lol:

Bien d'accord avec toi bigboomshakala, y'a que les macros que je met entièrement en majuscule, mais bon pourquoi pas ? C'est pas interdit...

D'ailleurs en parlant de macros, y'en a pas une qui s'appelle "M_PI" ? :wink:

J'ai tendance à mettre en majuscules les constantes connues à la compilation, pour les différentier des autres constantes, car ce sont des bêtes différentes (et ça facilite le portage de #define vers const...).

La solution classique fournie par Gandalf est un grand classique, elle marche bien et à le mérite de rattacher les constantes à une ou plusieur classes, ce qui évite de trimballer des données 'orphelines'.

Je suis pour le moins sceptique quand à la proposition de bigboomshakala de définir les constantes dans un namespace. Cette méthode ne permet pas de partager une même donnée entre plusieurs unité de compilation.
En terme d'édition de lien, un namespace n'a aucune existance. Cela revient à définir des variables globale. Or le seul moyen de partager une variable globale, c'est de préciser au compilateur que le symbole est externe à l'unité de compilation.

Code:

---

1 2	extern const int maConstante;

---

La méthode décrite défini les constante dans un ficher d'entête mais ne les déclare pas dans une unité de compilation spécifque. Par conséquent, toute les constantes seront redéfinies dans chaque unité de compilation incluant cet entête.
En gros, et pour faire clair, si on défini de cette manière une constante PI, chaque fichier source possèdera sa variable globale PI.
A part la perte de mémoire occasionnée, le reste est transparent puisque toutes ces variables sont initialisées de la même façcon. Ce n'est néanmoins pas une solution recevable.

Une autre solution couramment employée pour les constantes entières est de les définir par une énumération annonyme. Cette solution à le mérite de supprimer toute édition de lien, puisque le compilateur remplace directement la constante par sa valeur (cf. exmple ci-dessous).

Code:

---

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

enum {VERSION = 2}   struct Cube { enum {NB_FACE = 6}: };   int main() { cout << VERSION; cout << Cube::NB_FACE; }

---

remarque : c'est ce que fait Visual pour la définition des ID de ressource pour les classes de dialogue.
Par contre, j'ai du mal à saisir la nuance entre l'enum anonyme et l'attribut static const... Est-ce juste une différence de lieur ?

Citation:

---

Envoyé par tut

remarque : c'est ce que fait Visual pour la définition des ID de ressource pour les classes de dialogue.
Par contre, j'ai du mal à saisir la nuance entre l'enum anonyme et l'attribut static const... Est-ce juste une différence de lieur ?

---

Un enum n'a pas d'existance dans le code généré. Du point de vue de l'édition de lien, il a grosso modo la valeur d'un #define.
Alors que lors de l'execution, un static const est stocké en mémoire.

Un enum ne peut-etre qu'un entier alors qu'un static const peut-etre tu type que l'on veut.

Quand a mettre les globales dans un namespace :

Code:

---

1 2 3 4 5

namespace maths { const double PI=3.14159; };

---

c'est comme un enum, les variables const n'ayant pas d'existance en C++ (contrairement au C) il n'y aurra pas de gaspillage de mémoire...

Citation:

---

Envoyé par Gandalf

c'est comme un enum, les variables const n'ayant pas d'existance en C++ (contrairement au C) il n'y aurra pas de gaspillage de mémoire...

---

Alors c'est quelque chose que j'ignore. Tu as une référence la dessus ?
En tout cas, mon compilateur C++, lui ne l'entends pas de cette oreille. Je peux poster le code de test si tu veux. Si les variable globale const n'avaient pas d'existance, il ne serait pas nécessaire d'initialiser les membres statiques de classe.
Jusqu'à la preuve du contraire ceci est faux

EDIT: g++ 3.4.0

Une reference, tous les tutoriaux et cours de C++ enumerant les differences entre le C et la partie du C++ qui est compatible avec le C...

mais aussi Le Stroustrup Edition spéciale Francaise p 106


Cela est n'est bien sur pas le cas si la valeur de la constante n'est pas connue au moment de la compilation (resultat d'une fonction par exemple)

Mouais, je ne suis pas convaincu, et je doute que cela marche avec autre chose que des types scalaires. Franchement j'ai du mal à comprendre comment cela pourrait être compatible avec des contraintes de compilation séparée.
Mais, par acquis de conscience, j'ai testé là chose. Mes résultats expérimentaux ne correspondent pas à ce que tu dis.

Maintenant, si tu as un pointeur sur une doc accessible, je veux bien réviser mon jugement. Mes recherches sur google demeurant infructueuses.

Le Stroustrup VF 3e revu et corrigé par Michel Michaud ou un des précédents ? (ils contiennent divers contre-sens)

Sinon, un brouillon du comité qui peut traiter de ces détails est le document n1359. Je vous laisse l'éplucher :P

J'attend toujours ta doc Gandalf