Discussion :

[alaska90]

Bonjour,

Je me sert de .h pour stocker des typedef enum. Je souhaite savoir si l’initialisation de variable dans le .h est correcte ou pas ?
Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
typedef enum {
UN,
DEUX,
TROIS
}chiffre;
 
char chiffre2[] = "1 2 3";
 
int chiffre3 = 123;

D'avance merci.

[Bousk]

Le contenu d'un .h est copié dans l'unité de compilation avec les directives #include.
Tu peux déclarer des variables, mais elles seront différentes dans chaque unité de compilation.
Vue ta question, je doute que ce soit ce que tu veuilles faire.
extern ?

[alaska90]

Si c'est bien ça.
Selon mon defined symbol, j'appelle à la compilation le .h qui me convient avec #include. Donc, j'ai l'initialisation de mon enum que je souhaite.
Je voulais juste savoir si c'était "conventionnel" d'initialiser des variables des les .h.
Merci

[Bktero]

Ce n'est pas la bonne façon de procéder.

Ici, tes variables vont être dupliquées entre plusieurs `.c, elles auront le même nom, et donc au moment de l'assemblage des *.c pour faire un *.exe, tu auras une erreur "mutiple definitions of....".

La "bonne" solution d'avoir un *.h avec des déclarations avec le mot-clé "extern" et un *.c avec les définitions (là où tu leur donnes leurs valeurs). Je met des guillemets à "bonne" car tu fais là des variables globales et ce n'est pas souvent une "bonne" idée. Comme ce n'est pas le sujet de la discussion, je ne m'éternise pas là-dessus.

Une autre solution est de rajouter le mot-clé "static" dans ton *.h. A ce moment-là, chaque *.c recevra une instance différente de ton groupe de variables. Sauf que tu peux pas modifier celles de toto.c depuis titi.c et je ne suis pas sür que ça te convienne.

[alaska90]

Ici, tes variables vont être dupliquées entre plusieurs `.c, elles auront le même nom, et donc au moment de l'assemblage des *.c pour faire un *.exe, tu auras une erreur "mutiple definitions of....".

L'include du *.h n'est fait qu'à un seul endroit, seront-elles quand même dupliquées ?

La "bonne" solution d'avoir un *.h avec des déclarations avec le mot-clé "extern" et un *.c avec les définitions (là où tu leur donnes leurs valeurs). Je met des guillemets à "bonne" car tu fais là des variables globales et ce n'est pas souvent une "bonne" idée. Comme ce n'est pas le sujet de la discussion, je ne m'éternise pas là-dessus.

L'idée c'était d'avoir un *.h stockant seulement des variables, define, pas de méthode et sans *.c.

Une autre solution est de rajouter le mot-clé "static" dans ton *.h. A ce moment-là, chaque *.c recevra une instance différente de ton groupe de variables. Sauf que tu peux pas modifier celles de toto.c depuis titi.c et je ne suis pas sür que ça te convienne.

Ma variable ne doit pas être modifiée, je vais donc la passer en const. Static ne me convient pas car sont utilisation est limitée à son propre fichier.

[foetus]

L'idée c'était d'avoir un *.h stockant seulement des variables, define, pas de méthode et sans *.c.

Il faut mettre les include guards (<- lien wiki en français)

[Bktero]

L'include du *.h n'est fait qu'à un seul endroit, seront-elles quand même dupliquées ?

L'idée c'était d'avoir un *.h stockant seulement des variables, define, pas de méthode et sans *.c.

Ma variable ne doit pas être modifiée, je vais donc la passer en const. Static ne me convient pas car sont utilisation est limitée à son propre fichier.

Je pense que tu t'égares dans une mauvaise solution à un problème que tu ne nous a pas vraiment décrit.

Si tu inclus un *.h à un seul endroit (cet endroit étant logiquement un *.c), pourquoi avoir un *.h ? Pourquoi ne pas simplement mettre son contenu dans l'unique *.c où tu l'inclus ?

Cette idée me semble hautement bizarre. Quel est le vrai but de faire ça ?

Si elle ne doit pas être modifiée, alors ce n'est pas une variable, c'est uen constante. "#define" ou "static const" devrait faire l'affaire.
Tu dis que "static" ne te convient pas car limité à un fichier et pourtant tu as aussi dit que ton *.h est inclus une seule fois, ça ne me semble pas cohérent.

Il faut mettre les include guards (<- lien wiki en français)

Les include guards permettent de ne pas inclure plus fois le même *.h dans un fichier *.c, elles ne sont d'aucune aide face au problème de multiples définitions de variables.

[Sve@r]

Bonjour

Static ne me convient pas car sont utilisation est limitée à son propre fichier.

Tu n'as pas bien saisi le rôle de "static" qui, dans le cas d'une variable globale (ou même d'une fonction), est justement de limiter ladite variable (ou fonction) à son propre fichier...

L'include du *.h n'est fait qu'à un seul endroit, seront-elles quand même dupliquées ?

Ce n'est pas en utilisant un mauvais truc dans une configuration qui fait que ça marche que ça rend le truc correct. Peut-être qu'aujourd'hui ce ".h" ne sera inclus qu'une fois et donc que cela se passera bien mais tu auras pris une mauvaise habitude qui t'explosera au visage un jour ou l'autre.
Alors qu'il existe des solutions efficaces qui marchent dans toutes les configurations (surtout celle présentée hier par Bktero à base de "extern"), donc y compris pour un ".h" qui n'est inclus qu'une fois (et accessoirement là je rejoins Bktero sur le but de cette manoeuvre).

Je pense que tu t'égares dans une mauvaise solution à un problème que tu ne nous a pas vraiment décrit.

Problème XY...

[alaska90]

Selon la configuration choisie lors de la compilation, j'inclue un .h

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
ifdef A
    #include a.h
endif
ifdef B
    #include b.h
endif

Ces fichier a.h et b.h comprennent les mêmes noms de define, typedef enum et constantes.

fichier a.h

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
typedef enum{
TEST1,
TEST2
}enumerateur
const int entier = 1

fichier b.h

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
typedef enum{
TEST5,
TEST6
}enumerateur
const int entier = 4

Selon le fichier que j'inclue dans mon main, entier et enum n'auront pas les mêmes valeurs.
Initialiser la constante entier dans le .h comme je viens de l'écrire est-elle bonne ?

[dalfab]

Bonjour,

-On ne doit jamais utiliser de variables globales, ça donne un code ingérable.
-On ne doit jamais jamais définir de variables dans un header. Le C (pas le C++) tolère la redéfinition de variables donc pourrait fonctionner ici, mais cela est permis pour gérer le cas ingérable autrement de 2 variables pré-initialisées qui se référencent l'une l'autre.
-Et surtout on ne doit jamais jamais jamais définir des variables static dans un header, ça provoque des multidéfinitions qui amènent à des bugs complètement tordus (on croit utiliser une même variable alors qu'il en a plusieurs.)

Si ce sont des constantes, la règle devient:
-On peut les déclarer globales, ou y préférer utiliser des define (pas la même chose en C++).
-On ne les déclare surtout pas static. Ça provoque au mieux une consommation mémoire inutile, et si on venait en prendre l'adresse ça donnerais aussi des bugs tordus et quasi-impossibles à résoudre.

Dans ton cas, on peut considérer que ce ne sont pas des fichiers entête, ce sont des extraits de code. Il faut donc ne pas leur mettre le suffixe .h ni .c. Tu peux y mettre ce que du mets dans un .c et tu peux utiliser un autre suffixe, par exemple .selection ou autre.

[Sve@r]

Selon la configuration choisie lors de la compilation, j'inclue un .h

Tu mets directement tes directives dans un seul ".h" que tu inclus directement. Ou bien encore plus directement dans ton ".c".

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
#ifdef A
typedef enum{
	TEST1,
	TEST2
}enumerateur;
const int entier = 1;
#else // B
typedef enum{
	TEST5,
	TEST6
}enumerateur;
const int entier = 4;
#endif //A

Initialiser la constante entier dans le .h comme je viens de l'écrire est-elle bonne ?

Non. Voir premier post de Bktero à ce sujet. Tu déclares ta variable en "extern" dans le ".h" sans lui mettre de valeur, tu inclus ce ".h" partout où la variable est utilisée, et tu la définis dans un seul fichier ".c" (pour simplifier on choisit généralement celui qui contient le "main") et là tu lui initialises sa valeur.

On ne doit jamais utiliser de variables globales, ça donne un code ingérable.

Et on ne doit jamais dire "jamais" en prog. Je suis d'accord que les globales sont très souvent une fausse bonne idée mais elles existent néanmoins et donc, de fait, ont (ou peuvent avoir) un rôle à jouer, aussi minime soit-il. Si par exemple tu fais de la gestion de signal avec kill() et signal() tu ne pourras pas éviter les globales.

Et pour "améliorer" la gestion du code dans le cas d'utilisation de globales, il existe aussi certains outils (ou certaines façons d'écrire). Je présume que quand tu parles de code ingérable, tu fais (comme moi) référence à un code qui modifie des globales un peu partout sans trop se préoccuper du relecteur. Exemple

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
int v;
void toto() {
	... (du code, beaucoup de code)...
	v=123;
	... (du code, beaucoup de code)...
}

Un souci donc ici c'est que la modification de "v" est cachée par le fouillis du code avant et après. Et rien ne dit, au départ, que "toto" va modifier (voire même utiliser) "v". Mais si tu utilises judicieusement le extern...

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
int v;
void toto() {
	extern int v;
	... (du code, beaucoup de code)...
	v=123;
	... (du code, beaucoup de code)...
}

... hé oui, le extern n'est pas que réservé aux variables se trouvant dans un autre source lié à la compilation. Il a parfaitement le droit de faire référence localement à une variable globale située dans le même source. Ok c'est pas une protection absolue mais ça peut aider à savoir dès la première lecture que "toto" va utiliser "v"...

[alaska90]

Merci pour ces informations.

Tu mets directement tes directives dans un seul ".h" que tu inclus directement. Ou bien encore plus directement dans ton ".c".

Ces deux solutions ont déjà été faites. Je cherche une nouvelle solution pour le faire car le code devient illisible (trop de #ifdef...). Dans mon exemple j'ai mis deux cas, mais ça peut aller à plus de dix.

Dans ton cas, on peut considérer que ce ne sont pas des fichiers entête, ce sont des extraits de code. Il faut donc ne pas leur mettre le suffixe .h ni .c. Tu peux y mettre ce que du mets dans un .c et tu peux utiliser un autre suffixe, par exemple .selection ou autre.

C'est surement la bonne solution. Je vais voir comment faire ça. Merci

[Sve@r]

Je cherche une nouvelle solution pour le faire car le code devient illisible (trop de #ifdef...). Dans mon exemple j'ai mis deux cas, mais ça peut aller à plus de dix.

Hum, quand on en arrive à ce genre de situation où tu dépasses le stade de la simple compilation conditionnelle et où tu effondres le programmeur sous autant de cas à coder, alors peut-être essayer dans une autre direction totalement différente. Tu as dans ton post précédent parlé de configuration choisie. Tu peux alors te tourner vers un vrai fichier de configuration, le fameux ".ini" sous windows (ou .xxxrc sous Linux) qui est lu au début du programme. Ainsi ton code redescends en poids, redevient plus lisible et peut de lui-même s'adapter aux multiples cas de figures qui sont là et à celles qui peuvent arriver demain...

[alaska90]

Tu peux alors te tourner vers un vrai fichier de configuration, le fameux ".ini" sous windows (ou .xxxrc sous Linux) qui est lu au début du programme.

La solution est intéressante et bien adaptée. Merci pour vos explications !

[kaitlyn]

Bonjour,

Un entête en tant que fichier de configuration, avec quelques précautions ça me semble envisageable :

my_config.h :

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#if defined my_config
#pragma once
  int my_config_x_def_guard= 1;
 
  int common_var= 5;
 
  #if   my_config == 1 
     int a_var= 1; 
     //or #include "..."
     //...
 
  #elif my_config == 2
     int a_var= 2;
     //...
 
  #else 
     #error "oops! misconfiguration."
  #endif
 
#else
   #error "oops! improper use of my_config.h"
#endif

exemple d'utilisation :

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
#define my_config 2
#include "my_config.h"
 
#include <stdio.h>
int main(){
  printf("a_var= %d, common_var= %d", a_var, common_var);
}