Discussion :

[G3G3]

Bonjour,

J'ai une petite question concernant la priorité des opérateurs modulo et d'incrémentation. J'ai regardé le tableau donnant les priorités des opérateurs % et ++ : http://c.developpez.com/cours/bernar...ne/node101.php
mais je n'arrive pas à comprendre les résultats du code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
int i = 9;      // i = 9,    Ok
i = (i++)%10;  // i = 10,     ???

++ étant prioritaire sur % lui-même prioritaire sur =, je pensais que les opérations se déroulaient dans cet ordre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
int i = 9; 
i++; 
i = i%10;     // i = 0

Et pourtant il semble qu'elles soient exécutées comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
int i = 9; 
i = i%10; 
i++;   // i = 10

Je dois avouer que je n'y comprends pas grand chose, même les parenthèses n'y font rien. Si quelqu'un pouvait m'expliquer, je l'en remercie d'avance...

[Melem]

On s'en fout des priorités. Dans i = (i++) % 10, i++ est d'abord évalué : ça vaut 9 (puisque i = 9), ensuite 9 % 10 vaut 9 et on affecte ce résultat à i donc i = 9. Mais à la fin de l'instruction i est incrémenté (i++), on a alors finalement i = 10.

[Garulfo]

En règle générale : n'utilises pas ++ sur une variable que tu utilises à gauche et à droite de l'affectation.

Dans le cours que tu mentionnes :

À part quelques exceptions, l'ordre d'évaluation des opérandes d'un opérateur n'est pas spécifié par le langage. Ceci a pour conséquence que le programmeur doit faire extrêmement attention aux effets de bords dans les expressions. Par exemple, l'instruction :

t[i] = f();

où la fonction f modifie la valeur de i a un comportement indéterminé : il est impossible de savoir si la valeur prise pour indexer t sera celle de i avant ou après l'appel à f.

Ce qui est prioritaire c'est l'obtention de la valeur. Dans le cas de (++i), ce ne peut être obtenu qu'après avoir affecté l'incrément. Mais de le cas (i++) l'incrément étant calculé après ça n'est pas obligatoire. Et tu rendres dans le genre de détail qui me font toujours écrire des expressions sans ++ ou -- sauf dans les cas où on peut les remplacer par (+= 1). Ce sont des nids à pièges.

[Garulfo]

En même temps

[Médinoc]

Et j'en rajoute une couche:

• Tout ce qui est sous la forme "i = i++" est un comportement indéterminé.
• Tout ce qui est sous la forme "foo( i++, i++ )" est également un comportement indéterminé.

[souviron34]

d'ou l'interet, que je conseille TOUJOURS, d'eviter les increments "compactes" dans les expressions (en dehors des boucles, ou de certains algos tres specifiques (deplacement dans un tableau (et encore )), et de mettre des parentheses PARTOUT ou il y a PLUSIEURS conditions ou evaluations...

NE JAMAIS PRESUMER des ordres de priorite.... sauf dans le cas des ET (&&) ou l'on sait que l'on n'atteitn jamais la deuxieme condition si la premiere n'est pas remplie....

En bref, est-ce vraiment si penible d'ecrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
i = 9
i = i + 1
i = i % 10

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
i = 9
i = i  % 10
i = i + 1

???

et est-ce vraiment penible d'ecrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if ( (a == b) && ((c == d) || (g == f)) )

[Médinoc]

En bref, est-ce vraiment si penible d'ecrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
i = 9
i = i + 1
i = i % 10

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
i = 9
i = i  % 10
i = i + 1

Oui. Il est à la fois plus rapide et plus simple de faire ceci:

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
i = 9;
i++;
i %= 10;

Et tu remarqueras que cela ne fait aucune présomption sur les priorités: Ce code est 100% fiable.

et est-ce vraiment penible d'ecrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if ( (a == b) && ((c == d) || (g = f)) )

Non, c'est ce que je fais dès qu'utilise une expression un tant soi peu complexe.

[souviron34]

Oui. Il est à la fois plus rapide et plus simple de faire ceci:

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
i = 9;
i++;
i %= 10;

Et tu remarqueras que cela ne fait aucune présomption sur les priorités: Ce code est 100% fiable.
.

franchement : je vois ca dans un code industriel, je te mets un beau zero pointe
(je sais que ca se fait, je sais que le langage le permet, mais je le deconseille FORTEMENT)

[emprex]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
#include <stdio.h>
int main(void){
int i = 9;
i = (++i)%10;
printf("i vaut = %d\n",i);
return 0;
}

dans cette configuration nous avons le bon résultat. Mais est ce correcte?

[Médinoc]

Je crois bien que non, c'est toujours indéfini. Mais ça devrait marcher dans la plupart des implémentations, sans aucune garantie.

[Médinoc]

Corrigé:

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
#include <stdio.h>
int main(void) {
	int i = 9;
	++i;
	i =  i %10; /* ou i %= 10 */
	printf("i vaut = %d\n",i);
	return 0;
}

[diogene]

Et j'en rajoute une couche:

• Tout ce qui est sous la forme "i = i++" est un comportement indéterminé.
• Tout ce qui est sous la forme "foo( i++, i++ )" est également un comportement indéterminé.

tu as entièrement raison, et cette écriture est totalement à proscrire.

souviron34 :

Envoyé par Médinoc
Oui. Il est à la fois plus rapide et plus simple de faire ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
i = 9;
i++;
i %= 10;

Et tu remarqueras que cela ne fait aucune présomption sur les priorités: Ce code est 100% fiable.

franchement : je vois ca dans un code industriel, je te mets un beau zero pointe
(je sais que ca se fait, je sais que le langage le permet, mais je le deconseille FORTEMENT)

Et pourquoi ? C'est une position dogmatique ? Le code est clair, fiable et sans ambiguïté

[souviron34]

parce qu'en general, si on est adepte de ce genre d'ecriture, on arrive tres facilement au code obfusque....

Donc OUI c'est dogmatique....

Mais pragmatique....

Car le gars (ca m'est arrive, c'est pour ca que je le dit) qui fait de la maintenance sur site , dans le contexte d'une appli largement distribuee, avec contraintes de temps de delais d'intervention, n'a pas forcement a sa disposition ni toute la connaissance de la subtilite des notations, ni le temps de decoder une ligne bourree de += *=, %= , ++, (++)*(--), etc etc....

Donc, regle d'or d'un code industriel : lisibilite IMMEDIATE sans prise de tete...

Et comme c'est rigoureusement equivalent comme code genere, pourquoi faire complique quand on peut faire simple ???

un exemple : un contrat de maintenance prevoyant 4h de delai d'intervention MAX (le cas des applis medicales en milieu hospitalier). Une appli de traitement d'images sur un scanner.... 200 ou 300 mille lignes de code.... si les traitements sont ecrits comme ca....

[Garulfo]

Je pense que le code présenté par Médinoc est largement acceptable et que Souviron y va un peu fort

Cependant comme je disais personnellement j'évite ++ et --.
Et j'admet que %= n'est pas très agréable. Mais j'apprécie += ou *= par exemple.

[Melem]

Moi, j'ai rien contre les opérateurs ++, --, += et compagnie mais il ne faut pas en abuser (tout excès fait défaut !). Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

t[i++] = 0

: acceptable.
Mais pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

x *= (x++) + (y - x++)

ou comme dans l'exemple du P.O.

[Thierry Chappuis]

Mais pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

x *= (x++) + (y - x++)

ou comme dans l'exemple du P.O.

De toute manière ici, ce n'est pas une question d'accepter la notation ou pas. Le comportement est indéterminé. Point.

Thierry

[Melem]

De toute manière ici, ce n'est pas une question d'accepter la notation ou pas. Le comportement est indéterminé. Point.

C'est une des raisons pour la quelle il faut éviter ce genre d'écriture .