trou de memoire, fonction if en C
Bonjour tout le monde, et voila ma mémoire de débutant me fait défaut.
J'ai besoin de coder: si a est supérieur ou égal a 6 et inférieur ou égal a 7.
En gros la partie vrai est de 6 a 7, j'ai deux idée sur la façon de l’écrire mais je sais pas si ne serai ce qu une seul des deux est correcte:
première idée: if(a>=6,a<=7)
deuxième idée: if( (a>=6) && (a<=7) )
le pire c'est que les deux compiles
Donc n’hésiter pas a donner votre avis
Bonsoir,
la deuxième est toujours bonne car conforme aux normes de codage.
JR
l'électronique c'est pas du vaudou!
Lorsque tu mets une virgule, tu évalues plusieurs expressions à suivre. Dans le cas présent, le compilateur va évaluer a>=6, ignorer le résultat puisque tu n'en fais rien (et certains donc gcc vont te prévenir de cela) puis évaluer a<=7 et s'en servir pour le if.Envoyé par Dirk_Cooper
Bref, cela revient à écrire if(a<=7).
La 2nde syntaxe est correcte par contre.
D'accord merci pour vos réponses et merci a toi pm42 pour l'explication, je vais de ce pas modifier ça. ^^
les parenthèses ne sont pas utiles
if (a>=6 && a<=7)
elle le sont quand on fait une affectation dans le if
if ((a=b)>6 && a<=7) par exemple
Merci pour cette précision.
Sauf pour la lisibilité du code (cf. la titre de ce fil).
@+
Not only is it not right, it's not even wrong!
Bonjour,
+1000
On peut également dire que faire une affectation dans une expression comme dans l'exemple donné :
if ((a=b)>6 && a<=7)
est une très mauvaise idée. Notamment vu le nombre de fois où un if(x=0) a été écrit à la place de if(x==0).
Bonjour,
C'est un fait, on ne compte plus les bugs qui viennent de là.
Je recommande également de ne pas hésiter à parenthèser largement car on n'est jamais à l'abri d'un problème de priorité des opérateurs. De plus, ça ne coûte rien en terme de code généré.
je l'utilise souvent mais plutôt avec des fonctionsBonjour,
C'est un fait, on ne compte plus les bugs qui viennent de là.
if ((a=fonction(b))>2 && a <10) par exemple
@Jack
je ne vois pas où il y aurait un problème de priorité, c'est comme en math avec l’addition et la multiplication
on ne met pas les parenthèse dans ce cas (b*c) + (d*c) , on écrit b*c + d*c
mais on doit les mettre dans ce cas (b+c)*(d+c)
Mais est-ce que ça fait vraiment gagner du temps lors du codage/test/debug ? ? ?
c'est un peu comme écrire:
a = min(++a, b--);
selon que min est une fonction ou une macro, on risque de pleurer un peu ou beaucoup...
ou pire:
a = min(a++, b--); /* je sais, c'est moisi, mais un débutant risque de ne pas voir le piège... */
Tant qu'on se rappelle des règles de précédence...@Jack
je ne vois pas où il y aurait un problème de priorité, c'est comme en math avec l’addition et la multiplicationou (b*c) + (d*c)on ne met pas les parenthèse dans ce cas (b*c) + (d*c) , on écrit b*c + d*c
(ou (b+d)*c ...)Il vaut mieux un peu trop de parenthèses que pas assez.mais on doit les mettre dans ce cas (b+c)*(d+c)
Ayez une pensée à ceux qui ne connaissent pas le tableau des précédences et associativités par coeur...
enfin, c'est un point de vue, et on ne va pas (re)déclencher la guerre des parenthèses...
vim for ever ... (nan, je déconne, en dernier recours, c'est ed (ou sed))
Jusqu'ici tout va bien...
En effet et dans tous les cas, c'est une question de lisibilité et de maintenabilité : il vaut mieux écrire du code simple, robuste et ne pas trop se reposer sur des priorités, des ordres d'évaluation...
Cela marche tant qu'on a une expression simple, que le programmeur qui relit et maintient connait tout cela...
Et cela fait des bugs dès qu'on ajoute des termes à l'expression en ratant un effet de bord. Sachant que les dits effets de bord sont justement ce qu'on cherche à éviter à tout prix et qu'une branche entière des langages de programmation a été développé pour les supprimer entièrement, il est curieux d'en mettre.
Il faut que ça soit clair dans la tête du débutant...
Pour ce qui est de la priorité des opérateurs, elle est normalisée donc pas de risque de portabilité, en revanche, tout le monde connaît la priorité des +-*/, mais certaines priorités d'évaluation sont nettement moins évidente (comparateur, déréférencement, affectation etc...).
Sans parler de la différence entre a++ et ++a qu'on finit toujours par oublier alors que c'est vu dans les premières minutes de cours de C
