Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
[Debutant] Operateur d'incrementation
salut!!!
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.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
une idée?
Ici, le flot d'exécution mis en gras:
L'opérateur || n'évalue pas le second argument si le premier est vrai.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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; }
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
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...Envoyé par 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
EDIT : La norme dit que l'évaluation se fait de gauche à droite et qu'elle cesse dès qu'elle est retourne 1.
ou des catastrophes, c'est selon. Dans mon ex-boite (équipements de réseaux numériques), ce genre de pratique était tout simplement interdite.mais bien maitriser les prioritée des operateur et bien comprendre la facon de compiler peut apporter une certaine elegance dans un programme
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.
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.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Oups, j'ai dit une bétise. Je corrige.
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?
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é ?
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...sinon plus en rapport avec le C, est-ce qu'il existe un text en français de la norme dont tu parle?
Salut,
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
sera exécuté exactement de la meme manière que le code
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
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...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
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
qui aura exactement le meme résultat que si tu écris
Code : Sélectionner tout - Visualiser dans une fenêtre à part if(tontest)instruction1;instruction2
Tu gagne quatre lignes de code, mais tu perd énormément en lisibilité.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
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
A méditer: La solution la plus simple est toujours la moins compliquée
Bien sur que je n'est pas les connaissances pour en juger, je n'ai meme pas d'idée concrete pour bien manipuler les "string"mais les phrase du genre il faut eviter tel truc sans comprendre pourquoi, j'aime pas.
Comprendre un language sur le bout des doigts c'est savoir comment le compilateur reagit a n'importe quel situation.
justement l'anglais technique c'est lui qui me fait peur, parceque tu ne trouve aucun mot sur "Le petit larousse Anglais-Francais" mais bon... apparament y a pas le choix. t'aurai pas un lien stp?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...
t'exageres un peu la, t'aurais au moins pu mettre la dexieme instruction su une autre ligne
Ceci dit,
Dans un code du genre de
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
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).
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
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
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 if( j==4 && i=25)
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)
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
Petite astuce: la loi de Morgan s'applique en informatique
réagit de la meme manière que
Code : Sélectionner tout - Visualiser dans une fenêtre à part if(!(i!=3 || j!=5))
Code : Sélectionner tout - Visualiser dans une fenêtre à part if(i==3 && j==5)
Bien sur que j'ai exagéré...t'exageres un peu la, t'aurais au moins pu mettre la dexieme instruction su une autre ligne
Et je vais te faire un avoeux, c'était voulu... Pour la simple et bonne raisonn qu'un exemple pris de manière exagérée sera beaucoup plus percutant qu'un exemple classique... Les gens s'en souviendront bien mieux...
Quant au fait de douter de tout et de tout le monde, (y compris de soi meme), ca présente l'énorme avantage de t'inciter à etre sur que personne ne pourra faire une betise en utilisant ton application...
J'ai l'habitude de dire qu'il faut considérer l'utilisateur comme un imbécile distrait, si on veut etre sur qu'il ne provoquera jamais un comportement indéterminé (chaine trop longue, mauvaises valeurs...) Mais le codeur est aussi, d'une certaine manière, un utilisateur... et à ce titre, il a tout autant la possibilité, si pas d'être un imbécile, au moins d'etre distrait
Depuis quand la norme est-elle écrite en anglais? Elle est écrite en "standardese" qui est un language semi-formel basé sur l'anglais. En général, il faut déjà connaître l'ensemble du langage et comment il est décrit pour pouvoir découvrir quelque chose de manière sûre avec les normes des langages (enfin c'est le cas avec les 7 ou 8 que j'ai à un moment donné ou un autre considéré assez bien maîtriser, l'exception étant celle d'Ada83 -- Ada95 c'est à nouveau une autre histoire). En effet, une des caractéristiques de ces oeuvres, c'est que l'absence de répétition sémantique y est élevée en grand art (autrement dit s'il est possible de déduire une proposition P de choses écrites aux pages 12, 56, 78, 145 et 513 par un raisonnement en 42 étapes, P ne sera indiqué nulle part dans la norme, et le raisonnement encore moins. Si on a de la chance, un terme de P permettra de trouver dans l'index les pages 78 et 145, pour les autres, il faut se fier à sa connaissance).
À noter: il y a des parties des normes qui sont plus facilement compréhensibles et assez exemptes de pièges, la description des bibliothèques en général.
Non. On peut connaître en détail comment un compilateur réagit (et même connaître en détail comment tous les compilateurs réagissent), ça ne veut pas plus dire qu'on maîtrise le langage qu'avoir une connaissance parfaite de la chimie permet de dire qu'on maîtrise la biologie. D'ailleurs, il y a bien une période dans tous les langages où même ceux qui l'ont inventé et écrit le premier compilateur ne le maîtrise pas vraiment: ils n'ont pas encore assez d'expérience d'utilisation.
La page du comité et le document disponible librement le plus proche de la norme (en fait, c'est vraissemblablement le document le plus proche disponible).justement l'anglais technique c'est lui qui me fait peur, parceque tu ne trouve aucun mot sur "Le petit larousse Anglais-Francais" mais bon... apparament y a pas le choix. t'aurai pas un lien stp?
Le problème, c'est que pour différentes raisons (les deux principales étant le soucis d'accomoder les implémentations existantes au moment où la norme a été écrite et le soucis de permettre des implémentations performantes), la norme C permet aux implémentations d'avoir des comportements différents. On en trouve même plusieurs classes, du comportement défini par l'implémentation au comportement indéfini en passant par le comportement spécifique à la locale et le comportement non spécifié...
En particulier, une chose pour laquelle il est laissé de la lattitude à l'implémentation, c'est l'ordre d'évaluation des sous-expressions dans une expression composée. Tant qu'il n'y a pas d'effet de bord, les effets sont mineurs. Quand il y a des effets de bord (avec des fonctions mais aussi, surtout, avec les opérateurs d'incrémentation, de décrémentation et d'assignement), les choses deviennent plus complexe pour savoir ce qui est garanti et à quel moment. On utilise pour cela un modèle avec des points de séquencement auxquels la situation est un peu mieux définie. Mais si en général, les experts sont plus ou moins d'accord sur ce que veut permettre et interdire ce modèle, sa description n'est pas aussi précise que cela et on trouve des trous, des endroits où il interdit des choses qu'on aimerait bien autorisée, des endroits où il permet des choses qu'on aimerait bien interdites.
L'attitude d'Emmanuel (ne pas utiliser ce qui a des effets de bord en combinaison avec d'autres choses) est un peu extrême mais sensée. Le problème est qu'elle interdit des idiomes courants avec lesquels il faut être famillier même si on ne les emploie pas (while (*p++ != '\0') pour parcourir une chaîne par exemple). Mais il est difficile d'exprimer une règle sans risque plus fine (même si en pratique j'ai tendance à en utiliser une, je ne me risquerai pas à l'exprimer de peur de manquer un cas particulier, comme celui des opérateurs || && par exemple qui introduisent des points de séquencement).
On dirait le tractatus...
Il ne fait que 70 pages, la norme C en fait plus de 500.On dirait le tractatus...
Répondre avec citation
Partager