Bon, juste une question HS: j'ai cherché sans trouver une
option de gcc pour détecter les flexible array member,
sans succès.
J'ai mal cherché ou il n'y en a pas ?
C'est pour mes pauv' étudiants qui écrivent
struct Vecteur {
size_t size;
double val[];
};
en lieu et place de
struct Vecteur {
size_t size;
double *val;
};
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
6.3.1.2 Boolean type [1] When any scalar value is converted to *_Bool*, the result is 0 if the value compares equal to 0; otherwise, the result is 1.
Je ne la respecte pas ;-) C'est surtout à titre documentaire que bool m'intéresse. L'idée que quand on voit bool f() on sait que f retourne 2 valeurs.
B = 0; /* false */ B++; /* true */ B++; /* B inchangé, vaut toujours 1 ! */ B = B+1; /* idem, B inchangé, vaut toujours 1 ! */
1+B est un int car B est promu (rang plus faible, comme expliquait Laurent); le résultat de l'addition est donc 2; ensuite il s'agit de stocker le résultat dans B, donc il y a conversion, donc application de la règle ci-dessus...
... pas facile à réaliser avec un compilateur C89, n'est-ce-pas?
En effet. D'ailleurs, il me semblait que C++ ne le faisait pas, ayant introduit bool avant C, il n'avais pas pris cette règle. Faudrait que je vérifie.
Et si on fait un #if __STDC_VERSION__ >= 199901L #include <stdbool.h> #else typedef enum {true=1, false=0} bool; #endif on a quand même des problèmes ?
Cela dépend de ce que tu entends par problème(s). Je trouve que le comportement ci-dessus est suffisament non intuitif (quand on a été élevé dans l'idée que les booléens sont en fait des entiers) pour générer des problèmes si on essaye de faire semblant que « c'est pareil ».
Franchement, un pb lié à ce comportement comme ça, aucun élève ne me l'a fait dans les 3 dernières années...
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
In article <d627vf$7c7$1@shakotay.alphanet.ch>, Antoine Leca wrote:
En <news:d61ni7$h93$1@news.cict.fr>, Marc Boyer va escriure:
Laurent Deniau wrote:
Reste l'option C89 + #include <boyerbool.h>
typedef enum {true=1, false=0} bool;
Definition incompatible avec c99...
Ca m'avait échappé.
Comment fais-tu pour respecter la règle:
6.3 Conversions
6.3.1.2 Boolean type
[1] When any scalar value is converted to *_Bool*, the result is 0
if the value compares equal to 0; otherwise, the result is 1.
Je ne la respecte pas ;-)
C'est surtout à titre documentaire que bool m'intéresse. L'idée
que quand on voit
bool f()
on sait que f retourne 2 valeurs.
B = 0; /* false */
B++; /* true */
B++; /* B inchangé, vaut toujours 1 ! */
B = B+1; /* idem, B inchangé, vaut toujours 1 ! */
1+B est un int car B est promu (rang plus faible, comme expliquait Laurent);
le résultat de l'addition est donc 2; ensuite il s'agit de stocker le
résultat dans B, donc il y a conversion, donc application de la règle
ci-dessus...
... pas facile à réaliser avec un compilateur C89, n'est-ce-pas?
En effet.
D'ailleurs, il me semblait que C++ ne le faisait pas, ayant introduit
bool avant C, il n'avais pas pris cette règle. Faudrait que je vérifie.
Et si on fait un
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum {true=1, false=0} bool;
#endif
on a quand même des problèmes ?
Cela dépend de ce que tu entends par problème(s).
Je trouve que le comportement ci-dessus est suffisament non intuitif (quand
on a été élevé dans l'idée que les booléens sont en fait des entiers) pour
générer des problèmes si on essaye de faire semblant que « c'est pareil ».
Franchement, un pb lié à ce comportement comme ça, aucun élève ne me l'a
fait dans les 3 dernières années...
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
6.3.1.2 Boolean type [1] When any scalar value is converted to *_Bool*, the result is 0 if the value compares equal to 0; otherwise, the result is 1.
Je ne la respecte pas ;-) C'est surtout à titre documentaire que bool m'intéresse. L'idée que quand on voit bool f() on sait que f retourne 2 valeurs.
B = 0; /* false */ B++; /* true */ B++; /* B inchangé, vaut toujours 1 ! */ B = B+1; /* idem, B inchangé, vaut toujours 1 ! */
1+B est un int car B est promu (rang plus faible, comme expliquait Laurent); le résultat de l'addition est donc 2; ensuite il s'agit de stocker le résultat dans B, donc il y a conversion, donc application de la règle ci-dessus...
... pas facile à réaliser avec un compilateur C89, n'est-ce-pas?
En effet. D'ailleurs, il me semblait que C++ ne le faisait pas, ayant introduit bool avant C, il n'avais pas pris cette règle. Faudrait que je vérifie.
Et si on fait un #if __STDC_VERSION__ >= 199901L #include <stdbool.h> #else typedef enum {true=1, false=0} bool; #endif on a quand même des problèmes ?
Cela dépend de ce que tu entends par problème(s). Je trouve que le comportement ci-dessus est suffisament non intuitif (quand on a été élevé dans l'idée que les booléens sont en fait des entiers) pour générer des problèmes si on essaye de faire semblant que « c'est pareil ».
Franchement, un pb lié à ce comportement comme ça, aucun élève ne me l'a fait dans les 3 dernières années...
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
Antoine Leca
En <news:d629h4$ob9$, Marc Boyer va escriure:
Franchement, un pb lié à ce comportement comme ça, aucun élève ne me l'a fait dans les 3 dernières années...
Logique, peu de gens programment en pensant C99, avec des bool « binaires ». Mais le jour où cela deviendra plus courant, tu pourrais avoir le problème, des élèves te font du code qui utilisent cette propriété (qui est OK si tu compiles en mode C99), et le code n'est plus portable C99 avec ton <boyerboo.h> :-(
Enfin maintenant , tu sais de quoi il retourne, tu pourras expliquer (ce qui risque de ne pas être le plus facile, donc je te laisse cela comme exercice) de quoi il retourne à l'élève qui ne comprendra pourquoi son TP marche au poil chez lui (mode C99) et ne marche plus en classe (mode C89) ;-)
Antoine
En <news:d629h4$ob9$1@news.cict.fr>, Marc Boyer va escriure:
Franchement, un pb lié à ce comportement comme ça, aucun élève ne
me l'a fait dans les 3 dernières années...
Logique, peu de gens programment en pensant C99, avec des bool « binaires ».
Mais le jour où cela deviendra plus courant, tu pourrais avoir le problème,
des élèves te font du code qui utilisent cette propriété (qui est OK si tu
compiles en mode C99), et le code n'est plus portable C99 avec ton
<boyerboo.h> :-(
Enfin maintenant , tu sais de quoi il retourne, tu pourras expliquer (ce qui
risque de ne pas être le plus facile, donc je te laisse cela comme exercice)
de quoi il retourne à l'élève qui ne comprendra pourquoi son TP marche au
poil chez lui (mode C99) et ne marche plus en classe (mode C89) ;-)
Franchement, un pb lié à ce comportement comme ça, aucun élève ne me l'a fait dans les 3 dernières années...
Logique, peu de gens programment en pensant C99, avec des bool « binaires ». Mais le jour où cela deviendra plus courant, tu pourrais avoir le problème, des élèves te font du code qui utilisent cette propriété (qui est OK si tu compiles en mode C99), et le code n'est plus portable C99 avec ton <boyerboo.h> :-(
Enfin maintenant , tu sais de quoi il retourne, tu pourras expliquer (ce qui risque de ne pas être le plus facile, donc je te laisse cela comme exercice) de quoi il retourne à l'élève qui ne comprendra pourquoi son TP marche au poil chez lui (mode C99) et ne marche plus en classe (mode C89) ;-)
Antoine
Pierre Maurette
[...]
En effet. D'ailleurs, il me semblait que C++ ne le faisait pas, ayant introduit bool avant C, il n'avais pas pris cette règle. Faudrait que je vérifie. Effectivement, C++ ne "normalise" pas à l'affectation.
J'ignorais d'ailleurs que C99 le faisait ...
-- Pierre
[...]
En effet.
D'ailleurs, il me semblait que C++ ne le faisait pas, ayant introduit
bool avant C, il n'avais pas pris cette règle. Faudrait que je vérifie.
Effectivement, C++ ne "normalise" pas à l'affectation.
En effet. D'ailleurs, il me semblait que C++ ne le faisait pas, ayant introduit bool avant C, il n'avais pas pris cette règle. Faudrait que je vérifie. Effectivement, C++ ne "normalise" pas à l'affectation.
J'ignorais d'ailleurs que C99 le faisait ...
-- Pierre
Laurent Deniau
Pierre Maurette wrote:
[...]
En effet. D'ailleurs, il me semblait que C++ ne le faisait pas, ayant introduit bool avant C, il n'avais pas pris cette règle. Faudrait que je vérifie.
Effectivement, C++ ne "normalise" pas à l'affectation. J'ignorais d'ailleurs que C99 le faisait ...
D'ou l'interet d'une macro
#define BOOL_CAST(a) (!!(a))
a+, ld.
Pierre Maurette wrote:
[...]
En effet.
D'ailleurs, il me semblait que C++ ne le faisait pas, ayant introduit
bool avant C, il n'avais pas pris cette règle. Faudrait que je vérifie.
Effectivement, C++ ne "normalise" pas à l'affectation.
J'ignorais d'ailleurs que C99 le faisait ...
En effet. D'ailleurs, il me semblait que C++ ne le faisait pas, ayant introduit bool avant C, il n'avais pas pris cette règle. Faudrait que je vérifie.
Effectivement, C++ ne "normalise" pas à l'affectation. J'ignorais d'ailleurs que C99 le faisait ...
D'ou l'interet d'une macro
#define BOOL_CAST(a) (!!(a))
a+, ld.
Marc Boyer
Antoine Leca wrote:
En <news:d629h4$ob9$, Marc Boyer va escriure:
Franchement, un pb lié à ce comportement comme ça, aucun élève ne me l'a fait dans les 3 dernières années...
Logique, peu de gens programment en pensant C99, avec des bool « binaires ». Mais le jour où cela deviendra plus courant, tu pourrais avoir le problème, des élèves te font du code qui utilisent cette propriété (qui est OK si tu compiles en mode C99), et le code n'est plus portable C99 avec ton <boyerboo.h> :-(
En fait, quels sont les cas où cette propriété donne un résultat différent ? C'est quand on teste l'égalité entre deux booleens qui sont faux de manière différentes (ie l'un qui vaut 2, l'autre 3).
Enfin maintenant , tu sais de quoi il retourne, tu pourras expliquer (ce qui risque de ne pas être le plus facile, donc je te laisse cela comme exercice) de quoi il retourne à l'élève qui ne comprendra pourquoi son TP marche au poil chez lui (mode C99) et ne marche plus en classe (mode C89) ;-)
En fait, je savais que les _Bool étaient toujours 0 ou 1, donc je pense que j'aurais finit par trouver. Mais la propriété servant peut...
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
Antoine Leca wrote:
En <news:d629h4$ob9$1@news.cict.fr>, Marc Boyer va escriure:
Franchement, un pb lié à ce comportement comme ça, aucun élève ne
me l'a fait dans les 3 dernières années...
Logique, peu de gens programment en pensant C99, avec des bool « binaires ».
Mais le jour où cela deviendra plus courant, tu pourrais avoir le problème,
des élèves te font du code qui utilisent cette propriété (qui est OK si tu
compiles en mode C99), et le code n'est plus portable C99 avec ton
<boyerboo.h> :-(
En fait, quels sont les cas où cette propriété donne un résultat
différent ? C'est quand on teste l'égalité entre deux booleens
qui sont faux de manière différentes (ie l'un qui vaut 2, l'autre 3).
Enfin maintenant , tu sais de quoi il retourne, tu pourras expliquer (ce qui
risque de ne pas être le plus facile, donc je te laisse cela comme exercice)
de quoi il retourne à l'élève qui ne comprendra pourquoi son TP marche au
poil chez lui (mode C99) et ne marche plus en classe (mode C89) ;-)
En fait, je savais que les _Bool étaient toujours 0 ou 1,
donc je pense que j'aurais finit par trouver. Mais la propriété
servant peut...
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
Franchement, un pb lié à ce comportement comme ça, aucun élève ne me l'a fait dans les 3 dernières années...
Logique, peu de gens programment en pensant C99, avec des bool « binaires ». Mais le jour où cela deviendra plus courant, tu pourrais avoir le problème, des élèves te font du code qui utilisent cette propriété (qui est OK si tu compiles en mode C99), et le code n'est plus portable C99 avec ton <boyerboo.h> :-(
En fait, quels sont les cas où cette propriété donne un résultat différent ? C'est quand on teste l'égalité entre deux booleens qui sont faux de manière différentes (ie l'un qui vaut 2, l'autre 3).
Enfin maintenant , tu sais de quoi il retourne, tu pourras expliquer (ce qui risque de ne pas être le plus facile, donc je te laisse cela comme exercice) de quoi il retourne à l'élève qui ne comprendra pourquoi son TP marche au poil chez lui (mode C99) et ne marche plus en classe (mode C89) ;-)
En fait, je savais que les _Bool étaient toujours 0 ou 1, donc je pense que j'aurais finit par trouver. Mais la propriété servant peut...
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
Pierre Maurette
Pierre Maurette wrote:
[...]
En effet. D'ailleurs, il me semblait que C++ ne le faisait pas, ayant introduit bool avant C, il n'avais pas pris cette règle. Faudrait que je vérifie.
Effectivement, C++ ne "normalise" pas à l'affectation. J'ignorais d'ailleurs que C99 le faisait ...
D'ou l'interet d'une macro
#define BOOL_CAST(a) (!!(a)) C'est ce que je fais sans maquereau un peu plus haut dans ce fil.
Pour un travail qui ferait lourdement appel à de vrais booléens, il serait peut-être intéressant en C++ de faire une classe. J'avais commencé à y réfléchir à plusieurs reprises, puis c'est resté en l'air. En fait, j'utilise des classes, pour ce qui est d'en créer, c'est bof.
-- Pierre
Pierre Maurette wrote:
[...]
En effet.
D'ailleurs, il me semblait que C++ ne le faisait pas, ayant introduit
bool avant C, il n'avais pas pris cette règle. Faudrait que je vérifie.
Effectivement, C++ ne "normalise" pas à l'affectation.
J'ignorais d'ailleurs que C99 le faisait ...
D'ou l'interet d'une macro
#define BOOL_CAST(a) (!!(a))
C'est ce que je fais sans maquereau un peu plus haut dans ce fil.
Pour un travail qui ferait lourdement appel à de vrais booléens, il
serait peut-être intéressant en C++ de faire une classe. J'avais
commencé à y réfléchir à plusieurs reprises, puis c'est resté en l'air.
En fait, j'utilise des classes, pour ce qui est d'en créer, c'est bof.
En effet. D'ailleurs, il me semblait que C++ ne le faisait pas, ayant introduit bool avant C, il n'avais pas pris cette règle. Faudrait que je vérifie.
Effectivement, C++ ne "normalise" pas à l'affectation. J'ignorais d'ailleurs que C99 le faisait ...
D'ou l'interet d'une macro
#define BOOL_CAST(a) (!!(a)) C'est ce que je fais sans maquereau un peu plus haut dans ce fil.
Pour un travail qui ferait lourdement appel à de vrais booléens, il serait peut-être intéressant en C++ de faire une classe. J'avais commencé à y réfléchir à plusieurs reprises, puis c'est resté en l'air. En fait, j'utilise des classes, pour ce qui est d'en créer, c'est bof.
