Variable de type enumeration

candide a écrit :

Marc Espie a écrit :

Ou alors,
tu n'aimes pas Harbison & Steele ?

Très exactement. Et j'ai lu intégralement, crayon rageur à la main de la
page 1 à la page 324 donc tout ce qui concerne le langage et les
généralités concernant le_s_ bibliothèque_s_ (sic). Je me suis dispensé
de lire la descriptions une à une des fonctions standard mais je
consulte souvent la partie que je n'ai pas lu concernant des points
importants et délicats ou des questions ponctuelles. Je le consulte très
très souvent par ailleurs et ce sont toujours les mêmes défauts qui
reviennent d'absence de clarté, de mauvaise navigabilité (facheux pour
un ouvrage de référence). Je n'en finirais pas d'énumérer les défauts de
cet ouvrage un des pires que je connaisse, du mauvais travail, et comme
on en est à la cinquième édition, c'est que le travail était mal né. Je
ne remets pas pour autant en cause la compétence des auteurs, je crois
qu'elles est connue et reconnue.

Manque de bol, sur un axe tres precis, c'est effectivement un des
meilleurs
bouquins existants: c'est un tres bon ouvrage de reference vis-a-vis du
langage. Forcement moins exact que la norme, par construction, mais
egalement
sensiblement plus digeste.

Même pas sûr.

Oh que si !

Je ne l'ai jamais pris en defaut jusqu'ici.

Va voir l'errata tu seras impressionné de sa longueur. Des pans entiers
sont incorrects aux dires même des auteurs.

C'est une preuve d'honnêteté de la part des auteurs. D'autres, moins
scrupuleux, laissent leurs erreurs traîner de version en version...

Par contre, ca n'est clairement pas un bouquin d'apprentissage du C.

Non mais le niveau est étonnement hétérogène : il glose sur du trivial
et néglige le délicat.

Mais, sur ce plan, je ne sais pas s'il existe grand chose de correct en
dehors du K&R (qui est fort bien, mais quelque peu limite parfois)...

Fort bien ? bof, c'est un très mauvais ouvrage d'apprentissage, écrit
avec peu de rigueur pédagogique ou plutôt avec une rigueur pédagogique
très inégale, lumineux parfois, obscur et surchargé souvent. Je précise
que j'ai lu l'ouvrage crayon à la main de A à Z et c'est l'ouvrage que
je consulte en priorité pour tenter d'avoir une vue d'ensemble sur une
question donné sans compter qu'il contient du code hautement
idiomatique. Disons que le bouquin est correct quand on connait déjà
assez bien le langage ce qui est fâcheux pour un ouvrage qui est censé
vous l'apprendre.

Le K&R est anti-pédagogique !
Il m'est arrivé plusieurs fois de préconiser aux participants d'un cours
sur le langage C de mettre ce livre à la poubelle. C'est un des plus
mauvais sur le langage (pour l'apprentissage, je préfère le Harbison et
Steele, c'est peu dire...)

les autres bouquins auxquels j'ai jete un oeil sont le plus souvent
largement pires (en particulier, remplis d'erreurs et d'inexactitudes).

J'aimais bien le bouquin de Philippe Drix : langage C, norme ANSI,
sous-titré, vers une approche objet. Mais je ne sais pas s'il existe une
version actualisée après C99.

Hélas, il n'existe aucun bouquin ni même document décent sur le C (j'en
ai consulté ou lu des dizaines) mais il existe une multiplicité de
références plus ou moins correctes sur tel ou tel point plus ou moins
important. C'est pas compliqué tu prends une à une les questions plus ou
moins basiques sur le C qu'on lisait sur fclc il y a quelques années ou
encore maintenant sur clc voire sur csc et tu dois te rendre compte que
la réponse n'est dans aucun document figé. Pourtant, ces questions
répondent à un savoir figé (le C est une langue morte bien que toujours
parlé et étudié) et est connu de nombreuses personnes. Bien sûr, ce que
je te dis là vaut de beaucoup d'autres choses, en particulier tout ce
qui touche à l'utilisation d'outils informatiques où le savoir ne passe
pas par la documentation à moins d'être du sérail. Faut pas s'étonner
des succès de sites du genre le siteduzéro.

candide a écrit :

Marc Espie a écrit :

Les gens qui programment en C pour de vrai, dont je fais partie, ont
une tendance tres nette a NE PAS utiliser les bouts du langage les moins
clairs et les plus vicieux.

Je m'imagine à leur place et je pense que je ferais pareil. Mais bon, je
suis moins intéressé par la programmation en C que par son apprentissage
ou sa glose.

Ta phrase tendrait à dire, par analogie, que tu es plus intéressé par
l'apprentissage du dictionnaire et de la grammaire française que par
l'écriture du français ??
Ça paraît bizarre...

Mais à vrai dire, l'avis qui m'intéresse le plus est celui des
praticiens comme toi (et qui font qu'un langage mort peut être encore
vivant).

Le problème est qu'il faudrait délimiter objectivement ces questions se
référant à ces parties peu claires et vicieuses. Empoignades
interminables garanties.

Pour toi, j'ai retenu qu'il y avait déjà les variables globales (même si
le problème est un peu différent), les macro-fonctions et les enum.

Pour moi :
- les macros-fonctions
- les chaînes de caractères avec cette stupidité du pour marquer la
fin de chaîne. Il aurait plutôt fallu faire comme en PL/1
- l'équivalence pointeur/tableau
- la structure de bloc qui est bancale (on ne peut pas définir de
fonction à l'intérieur d'une fonction). Il n'y a donc pas de notion de
fonction locale (il n'y a que la notion de fonction statique...)
- le trop grand nombre de conversions implicites
- le typedef qui introduit une liaison forte entre les niveaux lexical
et syntaxique et qui n'est pas du "vrai" typage mais seulement de
l'homonymie.

Si ce sont des morceaux pour lesquels il est
difficile de trouver des reponses, il y a de tres fortes chances

T'es un pragmatique toi !

qu'une
part non negligeable des implementations soient fausses...

Implémentation de quoi ? du langage C ? parce qu'on mettre aussi en
cause les mauvaises pratiques des programmeurs et les incohérences
éventuelles de la norme.

Typiquement, tes questions recentes sur les enum. Les points un peu
bizarres de typage des enums font qu'une enum est tres rarement une bonne
idee, et qu'en tout cas il vaut mieux ne pas dependre des points obscurs
de la norme.

Je pense que ton avis sur les enum est loin de faire l'unanimité. Et si
tu regardes du code sérieux, tu sais bien que les énumérations sont très
utilisées.

Je suis d'accord avec toi, Candide. Le type enum, bien utilisé, rend de
nombreux services et il FAUT l'utiliser le plus possible.

En deux mots, pourrais-tu donner un exemple de code montrant un problème
soulevé par un type énuméré et dire par quoi tu remplaces tes enum (des
macro-constantes ? des variables const ?)

Tiens, pour alimenter la discussion, voici ce que dit K&R des
énumérations (numérotation et passages à la lignes sont de moi) :

-----------------------------------------------------------------------
Enumerations provide a convenient way to associate constant values with
names, an alternative to #define with the advantage that
(1) the values can be generated for you.

(2) Although variables of enum types may be declared, compilers need not
check that what you store in such a variable is a valid value for the
enumeration.


(3) Nevertheless, enumeration variables offer the chance of checking and
so are often better than #defines. In addition, a debugger may be able
to print values of enumeration variables in their symbolic form.
-----------------------------------------------------------------------

Mes questions :

(1) je comprends ce qu'il veut dire par ça. En clair, c'est quoi
l'avantage ? qu'on dispose de vraies variables ?

Un type enum est un ... type. #define n'indique aucun type pour un nom
et ce n'est pas une variable... (aucun contrôle ne peut être effectué
par le compilateur).

(2) phrase très ambiguë. Je vais quand même avoir un problème si je mets
un flottant dans une variable de type enum toto, ça le compilateur il va
le voir.

Ouais. Cette phrase est bizarre mais il y en a plein des comme ça dans
leur bouquin et ça reflète bien leur esprit assez tordu, il faut le dire...

(3) le checking, un réel avantage ? meilleure sécurité ?

C'est indéniable que c'est un avantage et que c'est un (petit) pas en
avant vers du code plus sécurisé. Cependant, écrire du code fiable de
bout en bout en C me paraît seulement à la portée des 5% de programmeurs
C qui maîtrisent totalement le langage (et encore).
En clair, si l'objectif de l'application est d'être extrêmement fiable
(car risque de perte de vies humaines sinon), je ne l'écrirait jamais en
langage C !!!

Par ailleurs, je précise que Kernighan et Pike recommandent dans "The
Pratice of Programming" (page 20) :

---------------- 8< ----------------------
Define numbers as constants, not macros.
[...]In C and C++, integer constants can be defined with an enum
statement as we saw in the previous example. [...]C has also const
values but they cannot be used as array bounds, so the enum statement
remains the method of choice in C.
------------------ >8 ---------------------

candide a écrit :

candide a écrit :

Par ailleurs, je précise que Kernighan et Pike recommandent dans "The
Pratice of Programming" (page 20) :

---------------- 8< ----------------------
[...]In C and C++, integer constants can be defined with an enum
statement

[...] so the enum statement ------------------ >8 ---------------------

Tiens "enum statement" ? ça existe ça ? Ce serait pas plutôt "enum
declaration" ?

Cette confusion est habituelle chez K&R.

Wykaaa a écrit :

Ta phrase tendrait à dire, par analogie, que tu es plus intéressé par
l'apprentissage du dictionnaire et de la grammaire française que par
l'écriture du français ??
Ça paraît bizarre...

Non, il y en a qui aiment écrire des romans, il y en a qui aiment les
lire, il y en a qui aiment les lire et les relire, il y en a qui aiment
les étudier. Ou si on veut être mauvaise langue, il y a les créateurs et
il y a les critiques.

Pour moi :
- les macros-fonctions
- les chaînes de caractères avec cette stupidité du pour marquer la
fin de chaîne. Il aurait plutôt fallu faire comme en PL/1
- l'équivalence pointeur/tableau
- la structure de bloc qui est bancale (on ne peut pas définir de
fonction à l'intérieur d'une fonction). Il n'y a donc pas de notion de
fonction locale (il n'y a que la notion de fonction statique...)
- le trop grand nombre de conversions implicites
- le typedef qui introduit une liaison forte entre les niveaux lexical
et syntaxique et qui n'est pas du "vrai" typage mais seulement de
l'homonymie.

OK mais dans tout ça, il y a plein de choses incontournables,
l'équivalence tableau-pointeur on peut pas s'en passer (Marc parlait des
choses à ne pas utiliser) et avec lesquelles on apprend très bien à
vivre (et qui me manqueront peut-être quand j'apprendrai autre chose que C).

(1) je comprends ce qu'il veut dire par ça. En clair, c'est quoi
l'avantage ? qu'on dispose de vraies variables ?

Un type enum est un ... type. #define n'indique aucun type pour un nom
et ce n'est pas une variable... (aucun contrôle ne peut être effectué
par le compilateur).

Je veux bien mais en quoi cela est-il la "traduction" de

(1) the values can be generated for you ?

(2) phrase très ambiguë. Je vais quand même avoir un problème si je
mets un flottant dans une variable de type enum toto, ça le
compilateur il va le voir.

Ouais. Cette phrase est bizarre mais il y en a plein des comme ça dans
leur bouquin et ça reflète bien leur esprit assez tordu, il faut le dire...

Esprit tordu ? Non, je ne pense pas, plutôt esprit malin, tellement
malin que leur livre est incompréhensible (sauf par certains esprits
avancés dont il existe ici quelques spécimens) par le débutant. Ils sont
tellement le langage dans la peau qu'il ne réalisent pas la polysémie de
certaines de leurs phrases.

avant vers du code plus sécurisé. Cependant, écrire du code fiable de
bout en bout en C me paraît seulement à la portée des 5% de programmeurs
C qui maîtrisent totalement le langage (et encore).

Et si c'était tout simplement parce que la doc est mal faite ?

Wykaaa a écrit :

Tiens "enum statement" ? ça existe ça ? Ce serait pas plutôt "enum
declaration" ?

Cette confusion est habituelle chez K&R.

Ah bon ? confusion entre "statement" et "declaration" ou juste entre
"enum statement" etc "enum declaration" ? t'as un exemple précis ?

Wykaaa a écrit :

langage. Forcement moins exact que la norme, par construction, mais
egalement
sensiblement plus digeste.

Même pas sûr.

Oh que si !

Oh que non ! Un exemple précis : Harbison and Steele sont infoutus dans
leur bouquin de définir ce que recouvre précisément le terme de
"statement" et il est FONDAMENTAL d'avoir des définitions précises en la
matière (cf. d'ailleurs la confusion déjà citée entre statement et
declaration). Dans HS, AUCUNE définition (alors qu'il y a un chapitre
portant le nom de "Statements" (chapitre 8). Incroyable ! de
l'amateurisme ! Et un jour, j'ai ouvert la norme et j'ai vu que le corps
du document contient des définitions relativement précises (en
particulier de "statement"). Et au début du texte il y a une clause qui
s'appelle "Definitions and conventions". Et tout a été amélioré entre
les versions de C90 à C99. Quand j'ai commencé le C, j'ai été accablé
par le jargon et un ouvrage de référence se doit d'en donner des
définitions, c'est évident.

Autre exemple : dans le § 5.5 sur les enumérations justement, ils ne
donnent AUCUN exemple d'une contruction d'une déclaration anonyme
d'énumération, un truc du genre :

enum {VRAI, FAUX};


eux systématiquement, ils écrivent

enum nonyme {VRAI, FAUX};

La norme, elle, donne des exemples pensés, et, ELLE, donne un tel
exemple. Or si je n'ai aucun exemple de certaines constructions (en plus
ici relativement usuelles), je ne vois pas comment je vais penser à les
utiliser à moins que je ne décide de déchiffrer la grammaire BNS du
langage C (ce qui est la présentation faite par HS et qu'ils
n'expliquent jamais, comme si tous les programmeurs de C connaissaient
la forme BNS d'une grammaire).

Et je pourrais multiplier les exemples où la norme est plus claire et
plus satisfaisante que HS.

C'est une preuve d'honnêteté de la part des auteurs. D'autres, moins
scrupuleux, laissent leurs erreurs traîner de version en version...

En effet mais je m'étonne qu'à la 5ème édition, il en reste autant.

Le K&R est anti-pédagogique !
Il m'est arrivé plusieurs fois de préconiser aux participants d'un cours
sur le langage C de mettre ce livre à la poubelle. C'est un des plus
mauvais sur le langage (pour l'apprentissage, je préfère le Harbison et
Steele, c'est peu dire...)

Je n'aime pas trop le K&R car il m'a fait beaucoup souffrir. Mais plus
je connais le C plus je trouve que le livre a des qualités de synthèse.
Et du beau code bien concis.

J'aimais bien le bouquin de Philippe Drix : langage C, norme ANSI,
sous-titré, vers une approche objet.

J'ai beaucoup aimé ce livre même s'il n'est pas si facile à lire. Et il
m'a aidé à fixer pas mal de choses.

Wykaaa a écrit :

Il est vrai que la littérature sur le langage C n'est pas terrible, à
commencer par le livre des auteurs du langage lui-même dans lequel de
nombreux exemples de code sont justement plutôt des exemples de ce qu'il
ne faudrait pas écrire en C...

Pas tant que ça je trouve, tu pensais à quoi ?

Il faut utiliser les enum en C pour ce qu'ils sont et les services
qu'ils peuvent rendre :
- augmenter la lisibilité des programmes. Il est toujours préférable de,
par exemple, nommer les jours que de se servir de 1, 2, 3, ..., 7
- Les enum doivent être utilisés conjointement avec switch.

C'est aussi comme ça que je vois les choses, il suffit de lire comment
sont gérées les touches du clavier d'un quelconque jeu écrit en C : des
enum et des switch. Et c'est très lisible.

D'une façon générale, il faut utiliser les enums en C comme ils sont
utilisés dans les autres langages, en particulier ADA.
Et surtout, il ne faut JAMAIS mélanger les enum et les int !

Donc tu abondes dans le sens de HS. Est-ce que tu aurais un exemple
précis du problème que ça peut poser ?

Donc un truc comme ça est fautif selon toi :


enum booleen {FAUX, VRAI} v1, v2=1-v1;


?

candide, le 03/07/2008 a écrit :

Bonjour,

Bonjour

[...]

Si, par exemple

enum toto {A4, BQ} t;

peut-on écrire

t(;

Oui et non.
Oui parce que ça compilera. Le seul risque est de passer pour un idiot
à la relecture, ou de faire sombrer le relecteur dans des abîmes de
perplexité s'il cherche à comprendre quelque chose.
Non parce que une obfuscation sans intérêt est simplement une erreur.
De plus ce code est certainement en désaccord avec toutes les règles de
style, et que violer une règle de style est une erreur.
Notez que la valeur n'a rien à voir. tQ serait peut-être encore plus
mauvais.
Bien entendu, le compilateur est à mon sens autorisé à warner, et un
lint quelconque à vous châtier.

(cela pourrait poser problème si l'on considère que les valeurs prises par
une variable de type enum toto sont parmi 34 et 51, cf. ma première citation
de la norme) ? Bon, en fait j'imagine que ça ne pose pas de problème
particulier mais je trouve que la norme n'est pas formelle sur ce point. Par
contre, pourrait-il y avoir des problèmes si on écrivait

t=-5;

?

Les valeurs négatives sont valides dans les enum. Et au passage rien
n'impose, sauf à respecter des règles de style, l'absence de doublons
implicites ou explicites:

enum toto {A = 34, B = 33, B1, C = 34, D = -1000} t;

Quelles précautions particulières prendre avec des variables de type
énumération ? Harbison & Steele recommandent une certaine prudence :


--------------------------- 8< ------------------------------------
We suggest that programmers treat enumerated types as different from integers
and not mix them in integer expressions without using casts.
--------------------------- >8 ------------------------------------

mais ils ne donnent aucun exemple illustrant les précautions à prendre.
Concrètement faut faire quoi ?

Oublier un peu la norme et la littérature et se fixer des règles de
bons sens. Les enum ne sont jamais indispensables, et directement
intéressantes essentiellement en liaison avec un switch...case (et à
mon avis c'est tout à fait réciproque). Et dans quelques cas déterminés
par le fait que la valeur sous-jacente des termes de l'enum ne doit pas
importer du tout, comme pour le switch...case. On s'imposera alors les
règles:
- Laisser l'enum se démerder, donc ne pas utiliser le forçage de
valeurs.
- Ne jamais présumer ni même tenir compte de la valeur numérique d'une
variable du type de l'enum. A une exception, si on ne fait pas de
forçage, on peut utiliser l'ordre dans lequel on a initialisé l'enum et
donc faire des comparaisons entre variables du même type enum.
- Ne jamais utiliser autre chose que des termes de l'enum, donc jamais
de valeurs numériques, dans le switch...case, ou un tableau, si on
décide de l'indicer par l'enum. Pas de résultats d'opérations entre des
variables de type de l'enum, ces résultats n'étant d'ailleurs pas dans
l'enum à priori.

Un exemple, en sachant qu'une structure serait sans doute plus adaptée:

enum{
COTE_FENETRE,
NB_FENTRES,
HAUTEUR_FENETRE,
LARGEUR_FENETRE,

UNUSED_SIZE_ELEM
};

unsigned long GEOMETRIE[UNUSED_SIZE_ELEM];

Je ne mets pas de cast sur UNUSED_SIZE_ELEM, je n'en vois pas
l'utilité.
On va pouvoir utiliser des trucs comme GEOMETRIE[HAUTEUR_FENETRE],
supposés être lisibles. Si on n'utilise jamais autre chose qu'un membre
de l'enum pour indicer GEOMETRIE, on peut en cours du développement
sans souci réordonner le machin, insérer de nouveau membres où bon nous
semble, et supprimer des membres de l'enum. Dans ce dernier cas, si on
continue à l'utiliser à un endroit, on aura une erreur.


Il y a un cas qui fait exception à toutes ces règles, et qui est
peut-être envisagé dans la norme. Ce sont les enum composées de valeurs
entières avec un seul bit allumé. On pourra s'autoriser une mise en OU,
pour ensuite faire une lecture par masquage par les éléments de l'enum.
Il faudra quand même être prudent, la taille exigée monte très vite.

Ainsi dans mon premier exemple ci-dessus,
dois-je écrire

t=(enum toto) 28;

?

??

A mon avis, ce qui est suggéré ici est que: imaginons qu'on soit
pragmatique et dans une République idéale sans la double Corse 2A 2B.
Nous pourrions penser nous simplifier la vie avec une enum des noms de
départements en correspondance avec leurs numéros. Nous obtiendrions
celà en copiant-collant une liste, puis en forçain AIN à 1, et
GUADELOUPE à 971. Je ne le ferais pas, sauf pour un programme jetable,
mais peu importe.
Maintenant nous voulons obtenir la chaîne "01" à partir de AIN, valeur
1. Alors, le texte suggère d'utiliser (int)AIN dans le ?printf().
Ou pour tester si un département est un DOM (comme la Corse ?), faire:
isDom(int dep){
return dep >= (int)GUADELOUPE && dep <= (int)LA_REUNION;
}

Tout celà fonctionnerait sans le cast, mais c'est certainement correct
de le systématiser.

--
Pierre Maurette

On 2008-07-06, Marc Espie <espie@lain.home> wrote:

Par contre, ca n'est clairement pas un bouquin d'apprentissage du C.
Mais, sur ce plan, je ne sais pas s'il existe grand chose de correct en
dehors du K&R (qui est fort bien, mais quelque peu limite parfois)...
les autres bouquins auxquels j'ai jete un oeil sont le plus souvent
largement pires (en particulier, remplis d'erreurs et d'inexactitudes).

J'ai reçu le "C Programming: a modern approach" de K.N. KING,
et il paraît pas mal à première vue.

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)

On 2008-07-06, candide <candide@free.invalid> wrote:

-----------------------------------------------------------------------
Enumerations provide a convenient way to associate constant values with
names, an alternative to #define with the advantage that
(1) the values can be generated for you.

(2) Although variables of enum types may be declared, compilers need not
check that what you store in such a variable is a valid value for the
enumeration.


(3) Nevertheless, enumeration variables offer the chance of checking and
so are often better than #defines. In addition, a debugger may be able
to print values of enumeration variables in their symbolic form.
-----------------------------------------------------------------------

Mes questions :

(1) je comprends ce qu'il veut dire par ça. En clair, c'est quoi
l'avantage ? qu'on dispose de vraies variables ?

Tu fais référence à quoi ? "the values can be generated for you" ?
ou "variables of enum types may be declared" ?

(2) phrase très ambiguë. Je vais quand même avoir un problème si je mets
un flottant dans une variable de type enum toto, ça le compilateur il va
le voir.

Je pense que ce qu'il veut signifier est que tu peux écrire:
enum T {a, b, c};
enum T e= 3;

(3) le checking, un réel avantage ? meilleure sécurité ?

Ben, oui, ça me paraît une évidence, non ?

Par ailleurs, je précise que Kernighan et Pike recommandent dans "The
Pratice of Programming" (page 20) :

---------------- 8< ----------------------
Define numbers as constants, not macros.
[...]In C and C++, integer constants can be defined with an enum
statement as we saw in the previous example. [...]C has also const
values but they cannot be used as array bounds, so the enum statement
remains the method of choice in C.
------------------ >8 ---------------------

Et oui. Comme il n'y a pas de système de constante correct en
C, on doit faire avec ce qu'on a.

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)