--------------------------- 8< ------------------------------------
Each enumerated type shall be compatible with an integer type; the
choice of type is implementation-defined.
--------------------------- >8 ------------------------------------
Ce qui n'est pas très clair c'est que par ailleurs :
--------------------------- 8< ------------------------------------
An identifier declared as an enumeration constant has type int.
--------------------------- >8 ------------------------------------
Je me pose donc la question de savoir si on peut utiliser sans risque
une variable de type énumération exactement comme s'il s'agissait d'une
variable de type int ? Je dis "sans risque" parce que formellement, je
crois que rien ne m'en empêche :
--------------------------- 8< ------------------------------------
A char, a short int, or an int bit-field, or their signed or
unsigned varieties, or an object that has enumeration type, may be
used in an expression wherever an int or unsigned int may be used.
--------------------------- >8 ------------------------------------
Si, par exemple
enum toto {A=34, B=51} t;
peut-on écrire
t=28;
(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;
?
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 ? Ainsi dans mon premier exemple ci-dessus,
dois-je écrire
Tu fais référence à quoi ? "the values can be generated for you" ?
oui
Bon, et je crois que tu as vu dans un autre message l'intérêt de ce genre de choses. Je n'y reviens pas.
(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;
Oui, je pense aussi que c'est ça.
Donc, ta question a sa réponse.
(3) le checking, un réel avantage ? meilleure sécurité ?
Ben, oui, ça me paraît une évidence, non ?
Que ça TE paraisse une évidence, j'en suis certain. En ce qui me concerne, non, je suis très peu sensibilisé à ça et depuis très peu de temps en plus. On a d'autres chats à fouetter quand on apprend le C.
Et pourtant. La question est: à quoi ça sert de connaître le C ? Ca permet de briller sur fclc, parfois autour de la machine à café au boulot, et assez peut dans les soirées. Mais ça permet surtout de programmer, en C. Je souligne que "en C" n'est pas le principal. Le but premier, c'est de programmer, le C n'est qu'un moyen. Et là, soit on considère que le programmeur ne fait pas d'erreur, et que le langage n'est pas là pour l'emmerder, soit on considère que le programmeur est faillible, et qu'il faut essayer de détecter ses potentielles erreurs, donc, les vérifications sont un plus. Après, il y a un équilibre à trouver entre un outil qui vérifie tout et contraint trop le programmeur, et celui qui le laisse libre de se tirer dans le pied sans rien dire. L'expérience montre que cet équilibre est difficile à trouver.
Je connaitrais d'autres langages avec un checking différent, genre python (à mon programme pour les mois à venir, oui, je sais qu'il y en a ici qui trouve que c'est un langage jouet mais j'ai plus envie de me prendre la tête), peut-être comprendrais-je mieux.
En effet, connaître plusieurs langages permet de prendre du recul sur chacun. Python ne me semble pas une mauvaise idée. Ruby me semblerait plus intéressant, mais bon, ça se discute...
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-07, candide <candide@free.invalid> wrote:
Marc Boyer a écrit :
Tu fais référence à quoi ? "the values can be generated for you" ?
oui
Bon, et je crois que tu as vu dans un autre message l'intérêt
de ce genre de choses. Je n'y reviens pas.
(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;
Oui, je pense aussi que c'est ça.
Donc, ta question a sa réponse.
(3) le checking, un réel avantage ? meilleure sécurité ?
Ben, oui, ça me paraît une évidence, non ?
Que ça TE paraisse une évidence, j'en suis certain. En ce qui me
concerne, non, je suis très peu sensibilisé à ça et depuis très peu de
temps en plus. On a d'autres chats à fouetter quand on apprend le C.
Et pourtant. La question est: à quoi ça sert de connaître le C ?
Ca permet de briller sur fclc, parfois autour de la machine à café
au boulot, et assez peut dans les soirées.
Mais ça permet surtout de programmer, en C. Je souligne que "en C"
n'est pas le principal. Le but premier, c'est de programmer, le C
n'est qu'un moyen.
Et là, soit on considère que le programmeur ne fait pas d'erreur,
et que le langage n'est pas là pour l'emmerder, soit on considère
que le programmeur est faillible, et qu'il faut essayer de détecter
ses potentielles erreurs, donc, les vérifications sont un plus.
Après, il y a un équilibre à trouver entre un outil qui vérifie
tout et contraint trop le programmeur, et celui qui le laisse libre
de se tirer dans le pied sans rien dire. L'expérience montre que
cet équilibre est difficile à trouver.
Je connaitrais d'autres langages avec un checking différent, genre
python (à mon programme pour les mois à venir, oui, je sais qu'il y en a
ici qui trouve que c'est un langage jouet mais j'ai plus envie de me
prendre la tête), peut-être comprendrais-je mieux.
En effet, connaître plusieurs langages permet de prendre du recul
sur chacun. Python ne me semble pas une mauvaise idée. Ruby me
semblerait plus intéressant, mais bon, ça se discute...
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Tu fais référence à quoi ? "the values can be generated for you" ?
oui
Bon, et je crois que tu as vu dans un autre message l'intérêt de ce genre de choses. Je n'y reviens pas.
(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;
Oui, je pense aussi que c'est ça.
Donc, ta question a sa réponse.
(3) le checking, un réel avantage ? meilleure sécurité ?
Ben, oui, ça me paraît une évidence, non ?
Que ça TE paraisse une évidence, j'en suis certain. En ce qui me concerne, non, je suis très peu sensibilisé à ça et depuis très peu de temps en plus. On a d'autres chats à fouetter quand on apprend le C.
Et pourtant. La question est: à quoi ça sert de connaître le C ? Ca permet de briller sur fclc, parfois autour de la machine à café au boulot, et assez peut dans les soirées. Mais ça permet surtout de programmer, en C. Je souligne que "en C" n'est pas le principal. Le but premier, c'est de programmer, le C n'est qu'un moyen. Et là, soit on considère que le programmeur ne fait pas d'erreur, et que le langage n'est pas là pour l'emmerder, soit on considère que le programmeur est faillible, et qu'il faut essayer de détecter ses potentielles erreurs, donc, les vérifications sont un plus. Après, il y a un équilibre à trouver entre un outil qui vérifie tout et contraint trop le programmeur, et celui qui le laisse libre de se tirer dans le pied sans rien dire. L'expérience montre que cet équilibre est difficile à trouver.
Je connaitrais d'autres langages avec un checking différent, genre python (à mon programme pour les mois à venir, oui, je sais qu'il y en a ici qui trouve que c'est un langage jouet mais j'ai plus envie de me prendre la tête), peut-être comprendrais-je mieux.
En effet, connaître plusieurs langages permet de prendre du recul sur chacun. Python ne me semble pas une mauvaise idée. Ruby me semblerait plus intéressant, mais bon, ça se discute...
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
candide
Marc Boyer a écrit :
Mais ça permet surtout de programmer, en C. Je souligne que "en C" n'est pas le principal. Le but premier, c'est de programmer, le C n'est qu'un moyen.
Bon, ça c'est encore une histoire de verre à moitié plein.
Et là, soit on considère que le programmeur ne fait pas d'erreur, et que le langage n'est pas là pour l'emmerder, soit on considère que le programmeur est faillible, et qu'il faut essayer de détecter ses potentielles erreurs, donc, les vérifications sont un plus. Après, il y a un équilibre à trouver entre un outil qui vérifie tout et contraint trop le programmeur, et celui qui le laisse libre de se tirer dans le pied sans rien dire. L'expérience montre que cet équilibre est difficile à trouver.
Bon finalement, la question du checking n'est pas si compliquée que ça, elle est même assez pragmatique.
Marc Boyer a écrit :
Mais ça permet surtout de programmer, en C. Je souligne que "en C"
n'est pas le principal. Le but premier, c'est de programmer, le C
n'est qu'un moyen.
Bon, ça c'est encore une histoire de verre à moitié plein.
Et là, soit on considère que le programmeur ne fait pas d'erreur,
et que le langage n'est pas là pour l'emmerder, soit on considère
que le programmeur est faillible, et qu'il faut essayer de détecter
ses potentielles erreurs, donc, les vérifications sont un plus.
Après, il y a un équilibre à trouver entre un outil qui vérifie
tout et contraint trop le programmeur, et celui qui le laisse libre
de se tirer dans le pied sans rien dire. L'expérience montre que
cet équilibre est difficile à trouver.
Bon finalement, la question du checking n'est pas si compliquée que ça,
elle est même assez pragmatique.
Mais ça permet surtout de programmer, en C. Je souligne que "en C" n'est pas le principal. Le but premier, c'est de programmer, le C n'est qu'un moyen.
Bon, ça c'est encore une histoire de verre à moitié plein.
Et là, soit on considère que le programmeur ne fait pas d'erreur, et que le langage n'est pas là pour l'emmerder, soit on considère que le programmeur est faillible, et qu'il faut essayer de détecter ses potentielles erreurs, donc, les vérifications sont un plus. Après, il y a un équilibre à trouver entre un outil qui vérifie tout et contraint trop le programmeur, et celui qui le laisse libre de se tirer dans le pied sans rien dire. L'expérience montre que cet équilibre est difficile à trouver.
Bon finalement, la question du checking n'est pas si compliquée que ça, elle est même assez pragmatique.
Marc Boyer
On 2008-07-08, candide wrote:
Mais ça permet surtout de programmer, en C. Je souligne que "en C" n'est pas le principal. Le but premier, c'est de programmer, le C n'est qu'un moyen.
Bon, ça c'est encore une histoire de verre à moitié plein.
Non, c'est une erreur de perspective, de recul. Le C n'est qu'un outil, dans le développement d'un système plus large. C'est une erreur fréquente des techniciens/ingenieurs que de se focaliser sur leur partie sans vouloir prendre en compte son intégration dans un projet plus large.
Et là, soit on considère que le programmeur ne fait pas d'erreur, et que le langage n'est pas là pour l'emmerder, soit on considère que le programmeur est faillible, et qu'il faut essayer de détecter ses potentielles erreurs, donc, les vérifications sont un plus. Après, il y a un équilibre à trouver entre un outil qui vérifie tout et contraint trop le programmeur, et celui qui le laisse libre de se tirer dans le pied sans rien dire. L'expérience montre que cet équilibre est difficile à trouver.
Bon finalement, la question du checking n'est pas si compliquée que ça, elle est même assez pragmatique.
La problématique est simple. La traiter est compliqué.
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-08, candide <candide@free.invalid> wrote:
Mais ça permet surtout de programmer, en C. Je souligne que "en C"
n'est pas le principal. Le but premier, c'est de programmer, le C
n'est qu'un moyen.
Bon, ça c'est encore une histoire de verre à moitié plein.
Non, c'est une erreur de perspective, de recul.
Le C n'est qu'un outil, dans le développement d'un système
plus large. C'est une erreur fréquente des techniciens/ingenieurs
que de se focaliser sur leur partie sans vouloir prendre en compte
son intégration dans un projet plus large.
Et là, soit on considère que le programmeur ne fait pas d'erreur,
et que le langage n'est pas là pour l'emmerder, soit on considère
que le programmeur est faillible, et qu'il faut essayer de détecter
ses potentielles erreurs, donc, les vérifications sont un plus.
Après, il y a un équilibre à trouver entre un outil qui vérifie
tout et contraint trop le programmeur, et celui qui le laisse libre
de se tirer dans le pied sans rien dire. L'expérience montre que
cet équilibre est difficile à trouver.
Bon finalement, la question du checking n'est pas si compliquée que ça,
elle est même assez pragmatique.
La problématique est simple. La traiter est compliqué.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Mais ça permet surtout de programmer, en C. Je souligne que "en C" n'est pas le principal. Le but premier, c'est de programmer, le C n'est qu'un moyen.
Bon, ça c'est encore une histoire de verre à moitié plein.
Non, c'est une erreur de perspective, de recul. Le C n'est qu'un outil, dans le développement d'un système plus large. C'est une erreur fréquente des techniciens/ingenieurs que de se focaliser sur leur partie sans vouloir prendre en compte son intégration dans un projet plus large.
Et là, soit on considère que le programmeur ne fait pas d'erreur, et que le langage n'est pas là pour l'emmerder, soit on considère que le programmeur est faillible, et qu'il faut essayer de détecter ses potentielles erreurs, donc, les vérifications sont un plus. Après, il y a un équilibre à trouver entre un outil qui vérifie tout et contraint trop le programmeur, et celui qui le laisse libre de se tirer dans le pied sans rien dire. L'expérience montre que cet équilibre est difficile à trouver.
Bon finalement, la question du checking n'est pas si compliquée que ça, elle est même assez pragmatique.
La problématique est simple. La traiter est compliqué.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
