Conditions avec des masques de bit - Page 1

Bonsoir,

Je suis en train de réviser un partiel de C (type QCM) avec des annales de l'an passé sans corrigé, et tout est relativement facile, sauf la dernière question que je trouve ambigue:



Une des expressions suivantes est correcte, laquelle ?

a) while(x & i<n)
b) while(x | i>=n)
c) while (!x && i<n)

Bien entendu, on veut probablement la c) . Cependant, après réflexion et tests au compilo, la a) et la b) passent quand même...il y'a t-il une subtilité que je n'ai pas saisie ?

Merci d'avance à celui qui saura éclairer ma lanterne

Peut-être que la réponse se trouve dans le type des variables ?
Ou bien ils veulent dire "correct par rapport aux conventions d'écriture qu'on a fixé dans le cours". Je me souviens que nous, nous n'avions pas le droit d'écrire des choses comme "i++;" en première année. On nous imposait "i=i+1;"

Étant donné qu'ils définissent pas ce qu'ils veulent dire par "correcte", non. Y'a rien qui t'empêche de choisir que "correcte" veut dire "compilable sans que le compilo signale une erreur", et dans ce cas-là, les 3 sont valables.

(et si on veut vraiment ergoter, on peut même dire que ça ne pose pas de problème, vu que "une des expressions suivantes est correcte" n'est pas "une et une seule des expressions suivantes est correcte", donc c'est un ou non-exclusif )

Mais bon, dans ce genre de cas, 99% de chances que c'est parce que tu es plus subtil que le gars qui a fait le sujet, et 99% de chances qu'il considère que la réponse est fausse si c'est pas celle qu'il attendait. Mets-toi dans la peau du gars qui réfléchit pas trop et réponds c), ça vaut mieux

c'est pas plutôt une histoire du genre que le résultat de a et b n'est pas défini parce qu'on sait juste que le résultat d'une comparaison est nul ou non (ptet que sur des plateformes "vrai" vaut 0xFFFFFFFF), et que faire une opération bit à bit sur une valeur non définie n'est pas non plus défini ?

Thibaut (./2) :
Peut-être que la réponse se trouve dans le type des variables ?
Ou bien ils veulent dire "correct par rapport aux conventions d'écriture qu'on a fixé dans le cours". Je me souviens que nous, nous n'avions pas le droit d'écrire des choses comme "i++;" en première année. On nous imposait "i=i+1;"

On a pas plus d'informations que ça sur le type des variables Tout est dans mon premier post.

Zerosquare (./3) :
Étant donné qu'ils définissent pas ce qu'ils veulent dire par "correcte", non. Y'a rien qui t'empêche de choisir que "correcte" veut dire "compilable sans que le compilo signale une erreur", et dans ce cas-là, les 3 sont valables.

(et si on veut vraiment ergoter, on peut même dire que ça ne pose pas de problème, vu que "une des expressions suivantes est correcte" n'est pas "une et une seule des expressions suivantes est correcte", donc c'est un ou non-exclusif )

Mais bon, dans ce genre de cas, 99% de chances que c'est parce que tu es plus subtil que le gars qui a fait le sujet, et 99% de chances qu'il considère que la réponse est fausse si c'est pas celle qu'il attendait. Mets-toi dans la peau du gars qui réfléchit pas trop et réponds c), ça vaut mieux

Ouais y'a des chances que ce soit ça...bon si j'ai le temps j'essaierais d'aller voir le prof, mais au pire je pense que c'est ça.

'faut dire que pour le i++, il faut avouer qu'il y a des pièges.
Voir cette discussion/flamewar sur dvp.com... http://www.developpez.net/forums/showthread.php?p=2467240#post2467240

aze (./4) :
c'est pas plutôt une histoire du genre que le résultat de a et b n'est pas défini parce qu'on sait juste que le résultat d'une comparaison est nul ou non (ptet que sur des plateformes "vrai" vaut 0xFFFFFFFF), et que faire une opération bit à bit sur une valeur non définie n'est pas non plus défini ?

Il me semble que la conversion d'une condition en entier donne toujours 1 si la condition est vraie (et pas juste un nombre différent de zéro), mais j'ai paumé mon K&R, donc je peux pas vérifier pour le moment...

EDIT (merci SCPCD) :

"Par definition, une expression arithmétique ou logique vaut 1 si la relation est vraie, 0 si elle est fausse"

D'apres le C90 :

a) while(x & i<n)

reviens a faire while((x & i) < n)

b) while(x | i>=n)

reviens a faire while((x | i) >= n)

c) while (!x && i<n)

reviens a faire while((!x) && (i < n))

Bref je pense que a b et sont valide, mais on obtiens pas ce qu'on pourrais croire

Godzil (./8) :

a) while(x & i<n)

reviens a faire while((x & i) < n)

Non.
Ça revient à faire x & (i<n).

b) while(x | i>=n)

reviens a faire while((x | i) >= n)

Et ça, ça revient à faire x | (i >= n).

C'est une erreur de conception qu'on reproche souvent au C, les opérateurs bit par bit se comportent comme les opérateurs logiques par rapport aux comparaisons, et ce n'est en général pas ce qu'on veut ou attend.

Zerosquare> ok, j'étais pas sûr

Kevin Kofler (./9) :

Godzil (./8) :

a) while(x & i<n)

reviens a faire while((x & i) < n)

Non.
Ça revient à faire x & (i<n).

b) while(x | i>=n)

reviens a faire while((x | i) >= n)

Et ça, ça revient à faire x | (i >= n).

C'est une erreur de conception qu'on reproche souvent au C, les opérateurs bit par bit se comportent comme les opérateurs logiques par rapport aux comparaisons, et ce n'est en général pas ce qu'on veut ou attend.

Pourtant d'apres le C90 le '|' et le '&' sont prioritaires sur les operations de comparaisons

C'est faux, relis ta copie du standard C (C90 ou C99, peu importe, ça n'a pas changé!). Cf. par exemple les sections 6.5.8, 6.5.9, 6.5.10, 6.5.11 et 6.5.12 du document WG14/N1124 (ISO/IEC 9899:TC2).

c'était tard NOTE: Ne plus lire de tableau en etant fatigué