Ordre de préséance des opérateurs ?

Salut !

En ce moment, je lis un livre sur le C++, " Programmation en C++, de John Hubbard, Edition Schaum, 1996". j'ai trouvé le code suivant, destiné à illustrer l'ordre d'exécution (ou préséance) des différents opérateurs, notamment la pré-et post incrémentation :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#include <iostream.h>   main() { int n = 5, x; x = ++n * --n; cout << "n = " << n << ", " << "x = " << x << endl; cout << ++n << " " << ++n << " " << ++n << endl;   system("PAUSE"); return 0; }

---

ça doit normalement afficher (selon le livre):

Code:

---

1 2	n = 5, x = 25 8 7 6

---

mais quand je compile avec DEV-C++, j'obtiens :

Code:

---

1 2	n = 5, x = 25 6 7 8

---

Je sais pas si c'est le livre qui est un peu vieux (les choses ont peut-être changé depuis), ou si c'est une erreur, j'ai pas compris. pouvez-vous m'aider à comprendre cet ordre de préséance ?

Merci !

Ton compilo ne bronche pas avec <iostream.h> ?
Si la réponse est non , change en.
Car maintenant c'est #include <iostream> et tout les compilateurs actuel (gcc,...) te diront que iostream.h c'est déprécié.

Sinon pour ton vrai problème , j'en sais rien.

Citation:

---

Programmation en C++, de John Hubbard, Edition Schaum, 1996

---

Tu peux changer de livre.
La date est déjà un bon indice. C++ a été standardisé en 1998.

Mon compilateur (récent et de qualité) ne donne aucun de tes deux résultats.
Tout simplement parce que a priori ça dépend de l'implémentation. (même pour la valeur de x)

De toutes manières, moi mon compilateur me donne un avertissement comme quoi le résultat n'est pas défini.

Citation:

---

Envoyé par hsazerty

Je sais pas si c'est le livre qui est un peu vieux (les choses ont peut-être changé depuis)

---

Les choses n'ont pas change. Le livre contient une erreur. Je conseille a nouveau de changer de livres: non seulement il est vieux, mais incorrect sur un sujet qu'un bon livre aurait mis un point d'honneur a expliquer correctement.

Salut !

Code:

---

1 2	n = 5, x = 25 8 7 6

---

voilà l'explication trouvée dans le livre pour expliquer le résultat :

"Dans l'affectation de x, n est d'abord incrémenté à 6 puis est décrémenté à 5 avant que l'opérateur de multiplication ne soit évalué, ce qui conduit au calcul de 5*5. A la dernière ligne, les trois sous-expressions sont évaluées de droite à gauche. L'associativité à gauche de l'opérateur de sortie << est sans objet parce qu'il n'y a pas d'autre opérateur de même niveau de préséance."

Ils ont l'air de savoir ce qu'ils disent, mais j'ai rien compris !

Bonjour,
j'ai testé les codes suivants (sous Dev et Visual C++)

Code:

---

1 2	int i = 1; cout << i++ << " " << i++ << endl;

---

Resultats :
Dev c++ : 1 2
VS 2005 : 2 1

de même

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

class Test { public : Test & Do( int i ); };   Test & Test::Do( int i ) { cout << i << " "; return *this; } [...] int i = 1; Test testeur; testeur.Do(i++).Do(i++);

---

Dev c++ : 1 2
VS 2005 : 2 1

Personnellement je croit que c'est le compilateur de Dev C++ à tort.
Ce que que j'ai compris (si je me trompe que les grand gourou du C++ me corrige :mouarf:) c'est que :
Un

Code:

---

A << B

---

équivaut à un

Code:

---

A.opertator <<( B )

---

si implémenté en tant que fonction membre de A
ou à un

Code:

---

opertator <<( A, B )

---

si implémenté en tant que fonction (le plus souvent amie pour accéder aux données protected/private).
Le c++ (le standard) n'impose pas comment est passé le "this" (pointeur vers l'objet) lors d'un appel, mais le plus souvent il est passé comme une sorte de premier paramètre invisible (ou du moins la fonctionnalité rendue est la même que si cela avait été la cas).
Donc

Code:

---

A << B

---

correspond à un

Code:

---

opertator <<( A, B )

---

En remplaçant operator << () par f() pour la lisibilité un

Code:

---

cout << i << j

---

équivaut à

Code:

---

f( f(cout,i) , j)

---

Or comme la convention d'appel du c++ évalue les paramètres de droite à gauche, j sera évalué puis f(cout,i) d'où le fait que dans cout << i++ << i++ le deuxième i++ est évalué en premier est retourne 1 tandis que i vaut 2 puis le second retourne 2 (tandis que i vaut alors 3).

- la précédence ne fixe pas l'ordre d'évaluation, elle la contraint simplement. C'est un moyen d'éviter de mettre des parenthèses.
- l'ordre d'évaluation des arguments n'est pas fixé en C++
- les effets de bords d'opérations comme ++ et -- sont encore moins contraints; modifier plus d'une fois un objet ou le lire pour faire autre chose que déterminer la valeur écrite est un comportement indéfini: le compilateur peut réellement faire n'importe quoi.

Citation:

---

Envoyé par gb_68

Bonjour,
j'ai testé les codes suivants (sous Dev et Visual C++)

Code:

---

1 2	int i = 1; cout << i++ << " " << i++ << endl;

---

---

La variable i est modifiée deux fois, le compilateur fait ce qu'il veut et il n'est pas obligé de prévenir (il y a des cas difficile à détecter), mais g++ -Wall me dit

Citation:

---

Envoyé par g++

cc.cc:6: warning: operation on i may be undefined

---

Citation:

---

Envoyé par Jean-Marc.Bourguet

- l'ordre d'évaluation des arguments n'est pas fixé en C++

---

Oui, c'est vrai :oops:.
Mais comme les conventions d'appels C++ passe les paramètres (dans la pile ou registre) de droite à gauche (sauf peut-être _fastcall de C++Builder, équivalente je crois à la register du Delphi/Pascal), le plus souvent les paramètres sont évalués de droite à gauche.

Exemple (qui donne celui-ci le même résultat sous VS et Dev c++)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

#include <cstdlib> #include <iostream>   using namespace std;   int f1() { cout << "appel de f1" <<endl; return 1; }   int f2() { cout << "appel de f2" <<endl; return 2; }   int main(int argc, char *argv[]) { cout << f1() << " " << f2() <<endl; system("PAUSE"); return 0; }

---

Resultat

Citation:

---

appel de f2
appel de f1
1 2
Appuyez sur une touche pour continuer...

---

On a bien 1 puis 2 (puisque f1() avant f2()) mais f2 a été appelée avant f1.

Du coup on prend de mauvaises habitudes :aie:.
Un article intéressant : http://www.ann.jussieu.fr/courscpp/S...Sect05-B5.html

Il ne faudrait donc jamais utiliser une fonction a effet de bord comme argument d'un autre fonction ... pas facile à respecter dans la pratique

Citation:

---

Envoyé par Jean-Marc.Bourguet

le compilateur peut réellement faire n'importe quoi.

---

+1
VS 2005

Code:

---

1 2	int i=0; cout << ++i << ++i <<endl;

---

Resultat 22 8O

Citation:

---

Envoyé par gb_68

Il ne faudrait donc jamais utiliser une fonction a effet de bord comme argument d'un autre fonction

---

Ca ne pose pas de problème (pour rappel dans cout << a << b << c, les opérateurs << ont des effets de bord). Ce qui pose problème c'est quand l'évaluation d'un argument dépend de l'effort de bord résultant de l'évaluation d'un autre argument. Et encore, le comportement alors n'est pas indéfini, simplement non spécifié (le compilateur ne doit pas commenter ce qu'il fait ni même être cohérent, mais le choix des comportements est limité, c'est évaluation dans un ordre ou dans un autre).

Le vrai problème c'est les opérations de base à effet de bord comme ++, --, -=... là on risque le comportement indéfini.

Bonsoir !

Tout ce que vous venez de dire c'est du charabia pour moi, je viens de débuter et je ne pige rien. Décidément le C++ est bien compliqué. :cry:


Merci quand même :D

Citation:

---

Envoyé par hsazerty

Salut !

Code:

---

1 2	n = 5, x = 25 8 7 6

---

voilà l'explication trouvée dans le livre pour expliquer le résultat :

"Dans l'affectation de x, n est d'abord incrémenté à 6 puis est décrémenté à 5 avant que l'opérateur de multiplication ne soit évalué, ce qui conduit au calcul de 5*5. A la dernière ligne, les trois sous-expressions sont évaluées de droite à gauche. L'associativité à gauche de l'opérateur de sortie << est sans objet parce qu'il n'y a pas d'autre opérateur de même niveau de préséance."

Ils ont l'air de savoir ce qu'ils disent, mais j'ai rien compris !

---

Si ça fonctionne comme les arguments d'une fonction, ça va dépendre des options de compilation...
Exemple :

Code:

---

1 2 3 4

void SampleFunction(int i, int j, int k) { std::cout << i << _T(" ") << j << _T(" ") << k << std::endl; }

---

ensuite on prend une pile qu'on remplie :

Code:

---

1 2 3 4

std::stack<int> Pile; Pile.push(1); Pile.push(2); Pile.push(3);

---

Ensuite on apelle notre fonction :

Code:

---

SampleFunction(Pile.pop(), Pile.pop(), Pile.pop());

---

Qu'est-ce qui se passe ???
Ben ça dépend de plein de choses :

• Si on est en __stdcall, __fastcall, __thiscall, ...
• D'option du compilo

Il est surement possible que la méthode pop de la librairie standard ne retourne pas la la valeur qui se trove qur le dessus de la pile, mais il est tout à fait possible de créer une pile qui s'utiliserai comme dans mon exemple...

Je trouve donc aussi que c'est débile de faire un exemple d'usage d'opérateur dans ce cadre la.... surtout si c'est pour des débutants !!!;)

Citation:

---

Envoyé par gb_68

Code:

---

1 2	int i=0; cout << ++i << ++i <<endl;

---

Resultat 22 8O

---

C'est un troll tu as fais exprès !! non ?! :twisted:

Citation:

---

Envoyé par gb_68

Or comme la convention d'appel du c++ évalue les paramètres de droite à gauche,

---

Je ne crois pas que le C++ définisse l'ordre d'évaluation des paramètres.
Et c'est même pire... en fonction de l'optimisation choisie l'ordre peut changer...

Par exemple:

Code:

---

1 2	funccall ( x*x , x*x*x );

---

Sans optimisation il calcule x*x*x et l'empile, puis x*x et l'empile à son tour.
Avec optimisation il caclule x*x d'abord (qu'il stock en registre R), empile R*x, puis empile R...

La définition des opérateurs aussi peut modifier la donne...

Quid de:
cout << 7 << 8 ?

cout << (7 << 8) => 1792
ou
(cout << 7) << 8 => 78


De toute manière, pour la facilité de relecture du code, il ne faut jamais préjuger l'ordre de calcul... les parenthèses servent à ça !
En même temps, le premier mec que je vois à écrire un truc genre: x = ++n * --n s'il est pas viré sur le champs, il va subir un serieux code-review ! :D

Citation:

---

Envoyé par hsazerty

Salut !

En ce moment, je lis un livre sur le C++, " Programmation en C++, de John Hubbard, Edition Schaum, 1996". j'ai trouvé le code suivant, destiné à illustrer l'ordre d'exécution (ou préséance) des différents opérateurs, notamment la pré-et post incrémentation :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#include <iostream.h>   main() { int n = 5, x; x = ++n * --n; cout << "n = " << n << ", " << "x = " << x << endl; cout << ++n << " " << ++n << " " << ++n << endl;   system("PAUSE"); return 0; }

---

ça doit normalement afficher (selon le livre):

Code:

---

1 2	n = 5, x = 25 8 7 6

---

mais quand je compile avec DEV-C++, j'obtiens :

Code:

---

1 2	n = 5, x = 25 6 7 8

---

Je sais pas si c'est le livre qui est un peu vieux (les choses ont peut-être changé depuis), ou si c'est une erreur, j'ai pas compris. pouvez-vous m'aider à comprendre cet ordre de préséance ?

Merci !

---

ton livre dit nimporte quoi et je vais en apporter la preuve !

Ensuite une simple lecture du source aurais pu t'apporter la réponse

Code:

---

1 2 3 4

int n = 5, x; x = ++n * --n; cout << "n = " << n << ", " << "x = " << x << endl; cout << ++n << " " << ++n << " " << ++n << endl;

---

en clair ca fais :

5->n
6*4->x (++n incremente la valeur de n (sans toucher à n) et --n decremente la valeur de n (sans toucher à n) le tout avant de faire la multiplication)

tu devrais donc obtenir n = 5, x = 24
6 7 8

la seule raison que je voie pour que tu obtienne 25 a la première opération est que tu ai rentré x = n++ * n--; en clair 5*5
n++ donne la valeur de n et l'incrémente apres la multiplication et n-- done la valeur 5 et la decrémente encore apres la multiplication

bonne soirée.

Citation:

---

Envoyé par doccpu

Jamais vu une bande de noob pareil :

1) tu peux jeter ton livre il dit nimporte quoi et je vais en apporter la preuve !

Ensuite une simple lecture du source aurais pu t'apporter la réponse

Code:

---

1 2 3 4

int n = 5, x; x = ++n * --n; cout << "n = " << n << ", " << "x = " << x << endl; cout << ++n << " " << ++n << " " << ++n << endl;

---

en clair ca fais :

5->n
6*4->x (++n incremente la valeur de n (sans toucher à n) et --n decremente la valeur de n (sans toucher à n) le tout avant de faire la multiplication)

tu devrais donc obtenir n = 5, x = 24
6 7 8

la seule raison que je voie pour que tu obtienne 25 a la première opération est que tu ai rentré x = n++ * n--; en clair 5*5
n++ donne la valeur de n et l'incrémente apres la multiplication et n-- done la valeur 5 et la decrémente encore apres la multiplication

bonne soirée.

---

Non arrete, rassure moi, c'est de l'ironie ton message ?

Passons le tas de conneries que tu raconte ; je ne suis vraiment pas convaincu que l'aggressivité soit utile ici.
Non mais franchement, quel prétention peux tu avoir ?!

Citation:

---

Envoyé par doccpu

Jamais vu une bande de noob pareil :

1) tu peux jeter ton livre il dit n'importe quoi et je vais en apporter la preuve !

Ensuite une simple lecture du source aurais pu t'apporter la réponse

Code:

---

1 2 3 4

int n = 5, x; x = ++n * --n; cout << "n = " << n << ", " << "x = " << x << endl; cout << ++n << " " << ++n << " " << ++n << endl;

---

en clair ca fais :

5->n
6*4->x (++n incremente la valeur de n (sans toucher à n) et --n decremente la valeur de n (sans toucher à n) le tout avant de faire la multiplication)

tu devrais donc obtenir n = 5, x = 24
6 7 8

la seule raison que je voie pour que tu obtienne 25 a la première opération est que tu ai rentré x = n++ * n--; en clair 5*5
n++ donne la valeur de n et l'incrémente apres la multiplication et n-- done la valeur 5 et la decrémente encore apres la multiplication
bonne soirée.

---

Citation:

---

Envoyé par Aszarsha

Non arrete, rassure moi, c'est de l'ironie ton message ?


Passons le tas de conneries que tu raconte ; je ne suis vraiment pas convaincu que l'aggressivité soit utile ici.
Non mais franchement, quel prétention peux tu avoir ?!

---

J'ai la prétention que j'ai mais je sait reconnaitre mes erreurs ! effectivement je me suis planté et je vais donc reprendre mon exposé seulement à 2h du mat je m'excuse de pas être trop clair.

Citation:

---

1) tu peux jeter ton livre il dit n'importe quoi et je vais en apporter la preuve !

Ensuite une simple lecture du source aurais pu t'apporter la réponse

Code:

---

1 2 3 4

int n = 5, x; x = ++n * --n; cout << "n = " << n << ", " << "x = " << x << endl; cout << ++n << " " << ++n << " " << ++n << endl;

---

en clair ca fais :

5->n
5*5->x (++n incremente la valeur de n (soit 6->n) et --n decremente la valeur de n (soit 5->n) le tout avant de faire la multiplication : n*n donc 5*5)

tu devrais donc obtenir n = 5, x = 25
6 7 8

la seule raison que je voie pour que tu obtienne 25 a la première opération est que tu ai rentré x = n++ * n--; en clair 5*5(ce morceau n'est plus d'actualité)

n++ donne la valeur de n et l'incrémente apres la multiplication et n-- done la valeur 5 et la decrémente encore apres la multiplication (ceci est une information qui peux être utile)

bonne journée.

---

J'ai mis en gras ce qui était erroné.

enfin je ne suis pas agressif (du moins je ne l'ai pas voulu) j'explique les choses.

Citation:

---

Envoyé par doccpu

la seule raison que je voie pour que tu obtienne 25 a la première opération est que tu ai rentré x = n++ * n--; en clair 5*5

6*4->x(++n incremente la valeur de n (sans toucher à n) et --n decremente la valeur de n (sans toucher à n) le tout avant de faire la multiplication)

---

sont les parties erronées. Au début je pensais à peu prés comme toi mais

Code:

---

x=++n * --n;

---

peut donnée 25 comme expliqué dans les autres réponses. Comme quoi on en apprend tout les jours:mouarf:

Ca peut donner 25, ça peut donner 42, ça peut donner 9841586437445165, ça peut formater ton disque dur, ça peut envoyer un mail d'insulte en ton nom à ton patron,... (bon, d'accord, les probabilités pour les derniers sont plus faibles que pour les premiers)

C'est ce qu'on appelle un comportement indéfini. En gros, c'est une erreur de programmation, mais il y a des cas où il n'est pas aisé (voire théoriquement impossible) de détecter ce type d'erreur, donc il n'a pas été exigé du compilateur qu'il la repère et refuse de compiler le programme. Un bon compilateur détectera ce problème dans les cas simples (voir la réponse de Jean-Marc).

merde j'ai fais un troll ! :(

non, non, c'est pas "ça peux", mais "ça doit" faire 5*5 = 25

pour la petite phrase que Mongaulois à relevé dans son dernier post était erronée et due a une erreur de raisonnement de ma part, due à une veille trop tardive et est donc complètement hors de propos. Je l'ai d'ailleurs expliqué dans mon dernier post

codiallement