On me pretend sans savoir justifier que pour definir des constantes
entieres il faut mieux
ecire
enum {
TOTO=1,
TITI=2
}
que
#define TOTO 1
#define TOTO 2
Qu'en pensez vous ? est juste une question d'habitude ou l'un est t'il
preferable et pourquoi ?
Moi je prefere le second car entourer par un ifdef il me permet
eventuelement de changer la valeur en la passant lors de la compile mais
est une bonne raison ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Emmanuel Delahaye
livier"none" wrote on 14/11/04 :
On me pretend sans savoir justifier que pour definir des constantes entieres il faut mieux ecire
enum { TOTO=1, TITI=2 }
que
#define TOTO 1 #define TOTO 2
Qu'en pensez vous ? est juste une question d'habitude ou l'un est t'il preferable et pourquoi ?
Je préfère la première méthode (à condition qu'elle soit correctement écrite)
enum { TOTO = 1, TITI = 2,
dummy };
ou plutôt
typedef enum { TOTO = 1, TITI = 2,
dummy } mes_constantes_e;
pour les raisons suivantes.
- Une constante définie par enum ne peut être redéfinie. - Le fait de typer la constante permet une organisation logique du code et des données. Une constante ne vient pas au hasard. Elle est le plus souvent le résultat d'une étude détaillée, qui montre qu'une variable (ou un paramètre) peut prendre telle ou telle valeurs, et rien d'autre. On peut regretter l'absence de véritable 'ensemble' en C (set), mais c'est comme ça, et enum est un ersatz acceptable. - La plupart des debogueurs utilise le typage de la constante pour afficher en chair son identificateur quand il est dans les bornes.
Par contre, il y a des limitations. Le type est int, ce qui interdit les valeurs au-dela de INT_MIN et INT_MAX. Dans ce cas, (ou chaine, flottant etc.), la macro s'impose. (Ne pas oublier de la typer avec le bon suffixe)
#define X 0x80000000UL
Moi je prefere le second car entourer par un ifdef il me permet eventuelement de changer la valeur en la passant lors de la compile mais est une bonne raison ?
Boaf, c'est plutôt dangereux... Mais c'est acceptable pour certaines macros impliquées dans de la compilation conditionelle.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
livier"none" wrote on 14/11/04 :
On me pretend sans savoir justifier que pour definir des constantes entieres
il faut mieux
ecire
enum {
TOTO=1,
TITI=2
}
que
#define TOTO 1
#define TOTO 2
Qu'en pensez vous ? est juste une question d'habitude ou l'un est t'il
preferable et pourquoi ?
Je préfère la première méthode (à condition qu'elle soit correctement
écrite)
enum
{
TOTO = 1,
TITI = 2,
dummy
};
ou plutôt
typedef enum
{
TOTO = 1,
TITI = 2,
dummy
}
mes_constantes_e;
pour les raisons suivantes.
- Une constante définie par enum ne peut être redéfinie.
- Le fait de typer la constante permet une organisation logique du code
et des données. Une constante ne vient pas au hasard. Elle est le plus
souvent le résultat d'une étude détaillée, qui montre qu'une variable
(ou un paramètre) peut prendre telle ou telle valeurs, et rien d'autre.
On peut regretter l'absence de véritable 'ensemble' en C (set), mais
c'est comme ça, et enum est un ersatz acceptable.
- La plupart des debogueurs utilise le typage de la constante pour
afficher en chair son identificateur quand il est dans les bornes.
Par contre, il y a des limitations. Le type est int, ce qui interdit
les valeurs au-dela de INT_MIN et INT_MAX. Dans ce cas, (ou chaine,
flottant etc.), la macro s'impose. (Ne pas oublier de la typer avec le
bon suffixe)
#define X 0x80000000UL
Moi je prefere le second car entourer par un ifdef il me permet eventuelement
de changer la valeur en la passant lors de la compile mais est une bonne
raison ?
Boaf, c'est plutôt dangereux... Mais c'est acceptable pour certaines
macros impliquées dans de la compilation conditionelle.
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
On me pretend sans savoir justifier que pour definir des constantes entieres il faut mieux ecire
enum { TOTO=1, TITI=2 }
que
#define TOTO 1 #define TOTO 2
Qu'en pensez vous ? est juste une question d'habitude ou l'un est t'il preferable et pourquoi ?
Je préfère la première méthode (à condition qu'elle soit correctement écrite)
enum { TOTO = 1, TITI = 2,
dummy };
ou plutôt
typedef enum { TOTO = 1, TITI = 2,
dummy } mes_constantes_e;
pour les raisons suivantes.
- Une constante définie par enum ne peut être redéfinie. - Le fait de typer la constante permet une organisation logique du code et des données. Une constante ne vient pas au hasard. Elle est le plus souvent le résultat d'une étude détaillée, qui montre qu'une variable (ou un paramètre) peut prendre telle ou telle valeurs, et rien d'autre. On peut regretter l'absence de véritable 'ensemble' en C (set), mais c'est comme ça, et enum est un ersatz acceptable. - La plupart des debogueurs utilise le typage de la constante pour afficher en chair son identificateur quand il est dans les bornes.
Par contre, il y a des limitations. Le type est int, ce qui interdit les valeurs au-dela de INT_MIN et INT_MAX. Dans ce cas, (ou chaine, flottant etc.), la macro s'impose. (Ne pas oublier de la typer avec le bon suffixe)
#define X 0x80000000UL
Moi je prefere le second car entourer par un ifdef il me permet eventuelement de changer la valeur en la passant lors de la compile mais est une bonne raison ?
Boaf, c'est plutôt dangereux... Mais c'est acceptable pour certaines macros impliquées dans de la compilation conditionelle.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
DINH Viêt Hoà
- Le fait de typer la constante permet une organisation logique du code et des données. Une constante ne vient pas au hasard. Elle est le plus souvent le résultat d'une étude détaillée, qui montre qu'une variable (ou un paramètre) peut prendre telle ou telle valeurs, et rien d'autre.
par contre, quand il s'agit de masques binaires, je n'ai pas encore de méthode appropriée vu qu'on ne peut pas trop typer ce genre de valeur.
(COIN | PINGOUIN) n'a ici aucune sémantique valable ...
-- DINH V. Hoa,
"tu as bientot 15 ans, faut que tu commences à être autonome" -- jul
- Le fait de typer la constante permet une organisation logique du code
et des données. Une constante ne vient pas au hasard. Elle est le plus
souvent le résultat d'une étude détaillée, qui montre qu'une variable
(ou un paramètre) peut prendre telle ou telle valeurs, et rien d'autre.
par contre, quand il s'agit de masques binaires, je n'ai pas encore de
méthode appropriée vu qu'on ne peut pas trop typer ce genre de valeur.
- Le fait de typer la constante permet une organisation logique du code et des données. Une constante ne vient pas au hasard. Elle est le plus souvent le résultat d'une étude détaillée, qui montre qu'une variable (ou un paramètre) peut prendre telle ou telle valeurs, et rien d'autre.
par contre, quand il s'agit de masques binaires, je n'ai pas encore de méthode appropriée vu qu'on ne peut pas trop typer ce genre de valeur.
(COIN | PINGOUIN) n'a ici aucune sémantique valable ...
-- DINH V. Hoa,
"tu as bientot 15 ans, faut que tu commences à être autonome" -- jul
Emmanuel Delahaye
DINH Viêt Hoà wrote on 14/11/04 :
- Le fait de typer la constante permet une organisation logique du code et des données. Une constante ne vient pas au hasard. Elle est le plus souvent le résultat d'une étude détaillée, qui montre qu'une variable (ou un paramètre) peut prendre telle ou telle valeurs, et rien d'autre.
par contre, quand il s'agit de masques binaires, je n'ai pas encore de méthode appropriée vu qu'on ne peut pas trop typer ce genre de valeur.
Exact. Pour les masques, j'utilise les macros :
http://mapage.noos.fr/emdel/clib/ed/inc/BITS.H
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
DINH Viêt Hoà wrote on 14/11/04 :
- Le fait de typer la constante permet une organisation logique du code
et des données. Une constante ne vient pas au hasard. Elle est le plus
souvent le résultat d'une étude détaillée, qui montre qu'une variable
(ou un paramètre) peut prendre telle ou telle valeurs, et rien d'autre.
par contre, quand il s'agit de masques binaires, je n'ai pas encore de
méthode appropriée vu qu'on ne peut pas trop typer ce genre de valeur.
Exact. Pour les masques, j'utilise les macros :
http://mapage.noos.fr/emdel/clib/ed/inc/BITS.H
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
- Le fait de typer la constante permet une organisation logique du code et des données. Une constante ne vient pas au hasard. Elle est le plus souvent le résultat d'une étude détaillée, qui montre qu'une variable (ou un paramètre) peut prendre telle ou telle valeurs, et rien d'autre.
par contre, quand il s'agit de masques binaires, je n'ai pas encore de méthode appropriée vu qu'on ne peut pas trop typer ce genre de valeur.
Exact. Pour les masques, j'utilise les macros :
http://mapage.noos.fr/emdel/clib/ed/inc/BITS.H
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
Emmanuel Delahaye
livier"none" wrote on 14/11/04 :
Merci reste deux questions.. 1) a quoi sert le dummy
a 'absorber' la ligne sans ',' (obligatoire en C90). Ca facilite la maintenance.
Dans le cas où les valeur sont implicite, remplacer le 'dummy' par 'nombre' ou NB. Car en effet, il donne le nombre de valeurs.
typedef enum { XX_X, XX_Y, XX_Z,
XX_NB } xx_e;
2) je vois pas trop ou est le control de type dans le bout de code suivant ou
Je n'ai *jamais* parlé de contrôle de type. On est en C. La sécurité dépend du programmeur (rappel : le C *n'est pas* un langage pour débutants).
Ceci-dit, quand c'est un pointeur qui est typé de la sorte, certains compilateurs s'autorisent des remarques si on utilise pas le bon type, ce qui est une Bonne Chose(c) ...
apres ton explication je m'attendais me faire jetter sur la ligne TTT =TOTO+12 mais j'ai sans doute mal pige
Le C est malheureusement laxiste. Si tu veux des contrôles sévères, utilise Pascal ou Ada.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
livier"none" wrote on 14/11/04 :
Merci reste deux questions..
1) a quoi sert le dummy
a 'absorber' la ligne sans ',' (obligatoire en C90). Ca facilite la
maintenance.
Dans le cas où les valeur sont implicite, remplacer le 'dummy' par
'nombre' ou NB. Car en effet, il donne le nombre de valeurs.
typedef enum
{
XX_X,
XX_Y,
XX_Z,
XX_NB
}
xx_e;
2) je vois pas trop ou est le control de type dans le bout de code suivant ou
Je n'ai *jamais* parlé de contrôle de type. On est en C. La sécurité
dépend du programmeur (rappel : le C *n'est pas* un langage pour
débutants).
Ceci-dit, quand c'est un pointeur qui est typé de la sorte, certains
compilateurs s'autorisent des remarques si on utilise pas le bon type,
ce qui est une Bonne Chose(c) ...
apres ton explication je m'attendais me faire jetter sur la ligne TTT
=TOTO+12
mais j'ai sans doute mal pige
Le C est malheureusement laxiste. Si tu veux des contrôles sévères,
utilise Pascal ou Ada.
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
Merci reste deux questions.. 1) a quoi sert le dummy
a 'absorber' la ligne sans ',' (obligatoire en C90). Ca facilite la maintenance.
Dans le cas où les valeur sont implicite, remplacer le 'dummy' par 'nombre' ou NB. Car en effet, il donne le nombre de valeurs.
typedef enum { XX_X, XX_Y, XX_Z,
XX_NB } xx_e;
2) je vois pas trop ou est le control de type dans le bout de code suivant ou
Je n'ai *jamais* parlé de contrôle de type. On est en C. La sécurité dépend du programmeur (rappel : le C *n'est pas* un langage pour débutants).
Ceci-dit, quand c'est un pointeur qui est typé de la sorte, certains compilateurs s'autorisent des remarques si on utilise pas le bon type, ce qui est une Bonne Chose(c) ...
apres ton explication je m'attendais me faire jetter sur la ligne TTT =TOTO+12 mais j'ai sans doute mal pige
Le C est malheureusement laxiste. Si tu veux des contrôles sévères, utilise Pascal ou Ada.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
Merci reste deux questions.. 1) a quoi sert le dummy 2) je vois pas trop ou est le control de type dans le bout de code suivant ou apres ton explication je m'attendais me faire jetter sur la ligne TTT =TOTO+12 mais j'ai sans doute mal pige
/*
#include<stdio.h> typedef enum{ TOTO=3, TATA=4,
dummy } mesconstante;
int main(){ mesconstante TTT; TTT=TOTO+12; /* c'est un int mais pas mesconstante */ printf("%d %d %d",TATA,TOTO,TTT); return 0;}
*/
Merci reste deux questions..
1) a quoi sert le dummy
2) je vois pas trop ou est le control de type dans le bout de code
suivant ou apres ton explication je m'attendais me faire jetter sur la
ligne TTT =TOTO+12
mais j'ai sans doute mal pige
/*
#include<stdio.h>
typedef enum{
TOTO=3,
TATA=4,
dummy
}
mesconstante;
int main(){
mesconstante TTT;
TTT=TOTO+12; /* c'est un int mais pas mesconstante */
printf("%d %d %d",TATA,TOTO,TTT);
return 0;}
Merci reste deux questions.. 1) a quoi sert le dummy 2) je vois pas trop ou est le control de type dans le bout de code suivant ou apres ton explication je m'attendais me faire jetter sur la ligne TTT =TOTO+12 mais j'ai sans doute mal pige
/*
#include<stdio.h> typedef enum{ TOTO=3, TATA=4,
dummy } mesconstante;
int main(){ mesconstante TTT; TTT=TOTO+12; /* c'est un int mais pas mesconstante */ printf("%d %d %d",TATA,TOTO,TTT); return 0;}
*/
Horst Kraemer
"@(none)" <""olivier"@(none)"> wrote:
Merci reste deux questions.. 1) a quoi sert le dummy 2) je vois pas trop ou est le control de type dans le bout de code suivant ou apres ton explication je m'attendais me faire jetter sur la ligne TTT =TOTO+12 mais j'ai sans doute mal pige
"Controle de type" ne veut pas dire "controle des limites". Un type enum est toujour compatible a un certain type entier choisi par l'implémentation (donc inconnu en principe), qui est capable de stocker toutes les membres de cet enum.
En général on n'utilise pas des variables d'un type "enum" pour stocker des valeurs qui ne sont pas des membres de ce type. Dans ce cas on préfère des variables d'un type intégral qui convient. L'intéret d'une *variable* du type "enum toto" est de stocker une des valeurs de ses membres. Quand elle peut contenir n'importe quoi son intérét "documenteur" a disparu.
-- Horst
"@(none)" <""olivier"@(none)"> wrote:
Merci reste deux questions..
1) a quoi sert le dummy
2) je vois pas trop ou est le control de type dans le bout de code
suivant ou apres ton explication je m'attendais me faire jetter sur la
ligne TTT =TOTO+12
mais j'ai sans doute mal pige
"Controle de type" ne veut pas dire "controle des limites". Un type
enum est toujour compatible a un certain type entier choisi par
l'implémentation (donc inconnu en principe), qui est capable de
stocker toutes les membres de cet enum.
En général on n'utilise pas des variables d'un type "enum" pour
stocker des valeurs qui ne sont pas des membres de ce type. Dans ce
cas on préfère des variables d'un type intégral qui convient.
L'intéret d'une *variable* du type "enum toto" est de stocker une des
valeurs de ses membres. Quand elle peut contenir n'importe quoi son
intérét "documenteur" a disparu.
Merci reste deux questions.. 1) a quoi sert le dummy 2) je vois pas trop ou est le control de type dans le bout de code suivant ou apres ton explication je m'attendais me faire jetter sur la ligne TTT =TOTO+12 mais j'ai sans doute mal pige
"Controle de type" ne veut pas dire "controle des limites". Un type enum est toujour compatible a un certain type entier choisi par l'implémentation (donc inconnu en principe), qui est capable de stocker toutes les membres de cet enum.
En général on n'utilise pas des variables d'un type "enum" pour stocker des valeurs qui ne sont pas des membres de ce type. Dans ce cas on préfère des variables d'un type intégral qui convient. L'intéret d'une *variable* du type "enum toto" est de stocker une des valeurs de ses membres. Quand elle peut contenir n'importe quoi son intérét "documenteur" a disparu.
-- Horst
Charlie Gordon
"@(none)" <""olivier"@(none)"> wrote in message news:419788d1$0$6387$
Bonjour
On me pretend sans savoir justifier que pour definir des constantes entieres il faut mieux ecire
enum { TOTO=1, TITI=2 }
que
#define TOTO 1 #define TOTO 2 // plutot TITI non ?
En fait cela dépend de l'utilisation que tu fais des identificateurs TOTO et TITI
Si tu t'en sers pour la compilation conditionnelle, il faut que ce soient des constantes du préprocesseur définies par macro. Il est important de noter que le préprocesseur expanse à 0 tout identificateur non défini dans une expression de controle de compilation conditionnelle. Ainsi par exemple :
#if CURRENT_VERSION == DEBUG_VERSION // ici du code de debug, compilé uniquement pour la version de debug #endif
si les constantes étaient définies avec une enum : enum { DEBUG_VERSION = 1, TEST_VERSION = 2, CURRENT_VERSION = TEST_VERSION };
#if CURRENT_VERSION == DEBUG_VERSION // ici le code est toujours compilé car ls ligne s'expanse à #if 0 == 0 : toujours vrai #endif
Ainsi il est préférable de définir TRUE et FALSE comme des macros et non simplement comme des valeurs enumérées pour que leur utilisation dans les directives de compilation conditionnelle produise le résultat escompté.
#if USE_NEW_VERSION == TRUE // compiler le code de la nouvelle version... #endif
On utilise en général des expressions de controle plus simples, mais éviter ce genre d'écueils du préprocesseur aux futurs mainteneurs du code n'est pas sans intérêt.
-- Chqlie
"@(none)" <""olivier"@(none)"> wrote in message
news:419788d1$0$6387$626a14ce@news.free.fr...
Bonjour
On me pretend sans savoir justifier que pour definir des constantes
entieres il faut mieux
ecire
enum {
TOTO=1,
TITI=2
}
que
#define TOTO 1
#define TOTO 2 // plutot TITI non ?
En fait cela dépend de l'utilisation que tu fais des identificateurs TOTO et
TITI
Si tu t'en sers pour la compilation conditionnelle, il faut que ce soient des
constantes du préprocesseur définies par macro.
Il est important de noter que le préprocesseur expanse à 0 tout identificateur
non défini dans une expression de controle de compilation conditionnelle. Ainsi
par exemple :
#if CURRENT_VERSION == DEBUG_VERSION
// ici du code de debug, compilé uniquement pour la version de debug
#endif
si les constantes étaient définies avec une enum :
enum {
DEBUG_VERSION = 1,
TEST_VERSION = 2,
CURRENT_VERSION = TEST_VERSION
};
#if CURRENT_VERSION == DEBUG_VERSION
// ici le code est toujours compilé car ls ligne s'expanse à #if 0 == 0 :
toujours vrai
#endif
Ainsi il est préférable de définir TRUE et FALSE comme des macros et non
simplement comme des valeurs enumérées pour que leur utilisation dans les
directives de compilation conditionnelle produise le résultat escompté.
#if USE_NEW_VERSION == TRUE
// compiler le code de la nouvelle version...
#endif
On utilise en général des expressions de controle plus simples, mais éviter ce
genre d'écueils du préprocesseur aux futurs mainteneurs du code n'est pas sans
intérêt.
"@(none)" <""olivier"@(none)"> wrote in message news:419788d1$0$6387$
Bonjour
On me pretend sans savoir justifier que pour definir des constantes entieres il faut mieux ecire
enum { TOTO=1, TITI=2 }
que
#define TOTO 1 #define TOTO 2 // plutot TITI non ?
En fait cela dépend de l'utilisation que tu fais des identificateurs TOTO et TITI
Si tu t'en sers pour la compilation conditionnelle, il faut que ce soient des constantes du préprocesseur définies par macro. Il est important de noter que le préprocesseur expanse à 0 tout identificateur non défini dans une expression de controle de compilation conditionnelle. Ainsi par exemple :
#if CURRENT_VERSION == DEBUG_VERSION // ici du code de debug, compilé uniquement pour la version de debug #endif
si les constantes étaient définies avec une enum : enum { DEBUG_VERSION = 1, TEST_VERSION = 2, CURRENT_VERSION = TEST_VERSION };
#if CURRENT_VERSION == DEBUG_VERSION // ici le code est toujours compilé car ls ligne s'expanse à #if 0 == 0 : toujours vrai #endif
Ainsi il est préférable de définir TRUE et FALSE comme des macros et non simplement comme des valeurs enumérées pour que leur utilisation dans les directives de compilation conditionnelle produise le résultat escompté.
#if USE_NEW_VERSION == TRUE // compiler le code de la nouvelle version... #endif
On utilise en général des expressions de controle plus simples, mais éviter ce genre d'écueils du préprocesseur aux futurs mainteneurs du code n'est pas sans intérêt.
-- Chqlie
Emmanuel Delahaye
livier"none" wrote on 14/11/04 :
Si y pas de control le typedef n'est la que pour ameliore la lisibilite ou est ce qu'il y a un autre difference entre typedef enum { XX_X, XX_Y, XX_Z,
XX_NB } xx_e;
et simplement
enum { XX_X, XX_Y, XX_Z,
XX_NB }
O.
Comme je l'ai déjà expliqué, le fait que le type soit nommé permet de typer les variables, voire les pointeurs sur ces variables.
int fa(xx_e data);
int fb(xx_e *p_data);
En dehors de l'aspect auto-documentaire, certains contrôles peuvent être faits.
{ int x = 123; fb (&x); /* warning. [1] */ }
------------ [1] Pas a cause de la valeur, evidemment, mais a cause du type.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
livier"none" wrote on 14/11/04 :
Si y pas de control le typedef n'est la que pour ameliore la lisibilite
ou est ce qu'il y a un autre difference entre
typedef enum
{
XX_X,
XX_Y,
XX_Z,
XX_NB
}
xx_e;
et simplement
enum
{
XX_X,
XX_Y,
XX_Z,
XX_NB
}
O.
Comme je l'ai déjà expliqué, le fait que le type soit nommé permet de
typer les variables, voire les pointeurs sur ces variables.
int fa(xx_e data);
int fb(xx_e *p_data);
En dehors de l'aspect auto-documentaire, certains contrôles peuvent
être faits.
{
int x = 123;
fb (&x); /* warning. [1] */
}
------------
[1] Pas a cause de la valeur, evidemment, mais a cause du type.
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
Ok pour le dummy, pour lautre une deniere precision (promis c la derniere;-)
Si y pas de control le typedef n'est la aue pour ameliore la lisibilite ou est ce qu'il y a un autre difference entre typedef enum { XX_X, XX_Y, XX_Z,
XX_NB } xx_e;
et simplement
enum { XX_X, XX_Y, XX_Z,
XX_NB }
O.
Hamiral
Qu'en pensez vous ? est juste une question d'habitude ou l'un est t'il preferable et pourquoi ?
Cela dépend. Un enum est une *énumération*. Pour moi, une énumération, c'est une liste de mots "numérotés", ou de numéros "nommés". Donc enum est parfait pour les constantes entières. Par contre pour les constantes flottantes et chaînes de caractères, les avis divergent sur l'utilisation de #define ou du mot-clé const.
Qu'en pensez vous ? est juste une question d'habitude ou l'un est t'il
preferable et pourquoi ?
Cela dépend. Un enum est une *énumération*. Pour moi, une énumération,
c'est une liste de mots "numérotés", ou de numéros "nommés". Donc enum
est parfait pour les constantes entières.
Par contre pour les constantes flottantes et chaînes de caractères, les
avis divergent sur l'utilisation de #define ou du mot-clé const.
Qu'en pensez vous ? est juste une question d'habitude ou l'un est t'il preferable et pourquoi ?
Cela dépend. Un enum est une *énumération*. Pour moi, une énumération, c'est une liste de mots "numérotés", ou de numéros "nommés". Donc enum est parfait pour les constantes entières. Par contre pour les constantes flottantes et chaînes de caractères, les avis divergent sur l'utilisation de #define ou du mot-clé const.
