Discussion :

[disturbedID]

salut!!!

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#include <stdio.h>
 
int main(int argc, char *argv[])
{
   int N, P, Q;
 
   N = 5; P = 2;
   Q = N++ > P || P++ != 3;
   printf ("1 :  N=%d P=%d Q=%d\n", N, P, Q);
 
   N = 5; P = 2;
   Q = N++ < P || P++ != 3;
   printf ("2 :  N=%d P=%d Q=%d\n", N, P, Q);
 
   return 0;
}

voila j'ai beau incliner la tete dans tout les sens, je ne vois pas pourquoi P vaut "2" lors du premier printf, et "3" lors du second.
une idée?

[Médinoc]

Ici, le flot d'exécution mis en gras:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#include <stdio.h>

int main(int argc, char *argv[])
{
   int N, P, Q;

   N = 5; P = 2;
   Q = N++ > P (vrai!) || P++ != 3;
   printf ("1 :  N=%d P=%d Q=%d\n", N, P, Q);

   N = 5; P = 2;
   Q = N++ < P || P++ != 3;
   printf ("2 :  N=%d P=%d Q=%d\n", N, P, Q);

   return 0;
}

L'opérateur || n'évalue pas le second argument si le premier est vrai.

[Emmanuel Delahaye]

Code :

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

1
2
3
 
   Q = N++ > P || P++ != 3;
   Q = N++ < P || P++ != 3;

Je déconseille formellement d'utiliser les opérateurs unaires (++ etc.) dans les expressions. Au pire, le comportement est indéfini ou dépend de l'implémentation. Au mieux, seuls quelques gourous de niveau 2 ou plus savent vraiment ce qui se passe...

[disturbedID]

Ohhhhh quel rapidité merci les gars. je comprend maintenant. c'est vrai, je n'y ai pas pensé. ainsi la deuxieme parti n'est pas évaluée.
Est ce valable pour tout les compilateur?

Mais c'est vrai que ce genre d'expression releve plus du jeu du "Keskispaceici" que d'une expression utile a mettre dans de vrais projets.

mais bien maitriser les prioritée des operateur et bien comprendre la facon de compiler peut apporter une certaine elegance dans un programme

[Emmanuel Delahaye]

Ohhhhh quel rapidité merci les gars. je comprend maintenant. c'est vrai, je n'y ai pas pensé. ainsi la deuxieme parti n'est pas évaluée.
Est ce valable pour tout les compilateur?

EDIT : La norme dit que l'évaluation se fait de gauche à droite et qu'elle cesse dès qu'elle est retourne 1.

mais bien maitriser les prioritée des operateur et bien comprendre la facon de compiler peut apporter une certaine elegance dans un programme

ou des catastrophes, c'est selon. Dans mon ex-boite (équipements de réseaux numériques), ce genre de pratique était tout simplement interdite.

Je me demande si les normes de codage MISRA ne font pas de même.

Toujours garder en tête que le code doit pouvoir être relu et vérifé de visu par un programmeur lambda (on a pas toujours les moyens de se payer un gourou..)

Alors le code 'élégant' mais illisible, c'est poubelle directe.

[Médinoc]

La norme dit que l'évaluation se fait de gauche à droite et que l'implémentation est libre de court-circuiter ou non.

Tu veux dire que le test if(unPointeur==NULL || *unPointeur==0) n'est pas garanti par la norme?

Si c'est bien ce que tu dis, j'entends déjà toute une génération de programmeurs (moi compris) dire un grand "oups!"...

Edit: OK, j'ai eu peur.

[Emmanuel Delahaye]

Tu veux dire que le test if(unPointeur==NULL || *unPointeur==0) n'est pas garanti par la norme?

Si c'est bien ce que tu dis, j'entends déjà toute une génération de programmeurs (moi compris) dire un grand "oups!"...

Oups, j'ai dit une bétise. Je corrige.

[koala01]

Ceci dit,

Dans un code du genre de

Tu veux dire que le test if(unPointeur==NULL || *unPointeur==0) n'est pas garanti par la norme?

La partie droite du ou (*unpointeur==0) ne sera effectivement évaluée QUE si la partie gauche ne renvoie pas vrai...

En effet la table de vérité d'un ou est

Code :

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

1
2
3
4
5
6
 
expr1 | expr2 |resultat
faux  |faux   |faux
faux  |vrai   |vrai
vrai  |faux   |vrai
vrai  |vrai   |vrai

Si bien qu'en électronique on peut parler de "détecteur de 0" en parlant d'une porte "OR" (la sortie ne vallant 0 que si toutes les entrées sont à 0).

En effet, dés le moment où l'expression est passée à VRAI, il n'y a plus de raison d'évaluer le reste (car cela ne changera plus: on a quitté l'état unique)

Par contre, dans un test

Code :

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

if( j==4 && i=25)

la partie droite de l'opérateur && (i=25) ne sera évaluée que si la partie gauche renvoie déjà vrai, car la table de vérifité de ET représente un état unique lorsque tout est vérifié:

Code :

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

1
2
3
4
5
6
 
expr1 | expr2 |resultat
faux  |faux   |faux
faux  |vrai   |faux
vrai  |faux   |faux
vrai  |vrai   |vrai

Dans ce cas, dés que le résultat passe à FAUX, il est inutile de continuer à évaluer le reste: le résultat restera FAUX (on a quitté l'état unique)

Petite astuce: la loi de Morgan s'applique en informatique

Code :

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

if(!(i!=3 || j!=5))

réagit de la meme manière que

Code :

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

if(i==3 && j==5)

[disturbedID]

ou des catastrophes, c'est selon. Dans mon ex-boite (équipements de réseaux numériques), ce genre de pratique était tout simplement interdite.

Je me demande si les normes de codage MISRA ne font pas de même.

Toujours garder en tête que le code doit pouvoir être relu et vérifé de visu par un programmeur lambda (on a pas toujours les moyens de se payer un gourou..)

Alors le code 'élégant' mais illisible, c'est poubelle directe.

Faut trouvé un juste compromis, si vraiment ce type de racourcis permet de gagner quelque lignes de code pour quoi pas?
S'il faut que les autres comprennent sa veut pas dire forcement qu'il faut que tu simplifis au maximum, les autre doivent aussi maitriser un minimum.
C'est comme si tu demander a un poete du XVIIIeme d'ecire en language star'AC, pour que tout le monde comprennent. Ben non c'est au autres d'elever le niveu.

sinon plus en rapport avec le C, est-ce qu'il existe un text en français de la norme dont tu parles?

[Emmanuel Delahaye]

Faut trouvé un juste compromis, si vraiment ce type de racourcis permet de gagner quelque lignes de code pour quoi pas?

Si le code est garanti sans UB (Undefined Behaviour ou Comportement Indefini) ni dépendant de l'implémentation, OK. Tu en es sûr ? Tu as les connaissances requises pour en juger ? Idem pour les vérifieurs du service de Qualité ?

sinon plus en rapport avec le C, est-ce qu'il existe un text en français de la norme dont tu parle?

Non. L'anglais et requis pour faire de l'informatique. Franchement, lire de l'anglais technique, c'est pas méchant. C'est pas du Shakespeare ou du Beckett...

[koala01]

Salut,

Faut trouvé un juste compromis, si vraiment ce type de racourcis permet de gagner quelque lignes de code pour quoi pas?
S'il faut que les autres comprennent sa veut pas dire forcement qu'il faut que tu simplifis au maximum, les autre doivent aussi maitriser un minimum.
C'est comme si tu demander a un poete du XVIIIeme d'ecire en language star'AC, pour que tout le monde comprennent. Ben non c'est au autres d'elever le niveu.

Sauf qu'au niveau de l'exécutable généré en lui-meme, ce n'est pas le nombre de ligne du code que tu auras écrit qui fera une différence du point de vue de la rapidité d'exécution... Du moins dans l'exemple que tu donnes.

Si tu es "fade" au point de vouloir éviter l'écriture de quatre lignes, mais que tu préfères perdre 20 minutes dans trois mois pour te relire, honnetement, tu fais un mauvais calcul...

Je te rappelle que, dés que tu fais une affectation ou une comparaison avec une instruction du coté droit, l'instruction doit etre effectuée avant que l'affectation ou la comparaison ne puisse avoir lieu...

Un code du genre de

Code :

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

1
2
3
4
5
 
if(i==++j)
{
    //ce qu'il faut faire
}

sera exécuté exactement de la meme manière que le code

Code :

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

1
2
3
4
5
6
 
++j;
if(i==j)
{
    //ce qu'il faut faire
}

La différence, c'est que dans le premier cas, noyé dans le reste de ton code, tu risque de rater le fait que j est incrémenté avant le test...

Dans le deuxieme cas, par contre, tu risque beaucoup moins de rater ce fait.

De la meme manière, les accolades ne sont pas indispensables quand tu n'as qu'une seule instruction à effectuer si un test est vérifié...

Tu peux donc parfaitement écrire

Code :

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

if(tontest)instruction1;instruction2

qui aura exactement le meme résultat que si tu écris

Code :

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

1
2
3
4
5
if(tontest)
{
    instruction1;
}
instruction2;

Tu gagne quatre lignes de code, mais tu perd énormément en lisibilité.

Or, s'il y a un principe qu'il faut garder en tete, c'est celui du "on ne peut etre sur de rien"... et meme de ca, on peut en douter ...

Au moment où tu écris ton code, il te semble parfaitement compréhensible, mais, imaginons, simplement qu'apres l'avoir écrit, tu te casse la jambe en rentrant chez toi, et que tu doives le reprendre trois mois plus tard (apres t'etre fait soigner)...

Es tu sur que ton code te paraitra aussi limpide? Personnellement, j'ai un doute