Priorités des opérateurs

Bonjour,

je me pose des questions sur la priorité des opérateurs. Pour des nombres a,b,c,d le code

Code:

---

1 2

d = a*b+c

---

est équivalent à

Code:

---

1 2	d = (a*b)+c

---

car * est prioritaire sur +. J'ai deux questions simples à ce propos :

1. est-ce toujours vrai si a,b,c,d sont des objets quelconques et * et + ont été surchargés?

2. la norme précise-t-elle la priorité entre opérateurs identiques? Par exemple, la ligne

Code:

---

1 2

d = a*b*c

---

correspond-elle à

Code:

---

1 2	d = (a*b)*c

---

ou à

Code:

---

1 2	d = a*(b*c).

---

Bien sûr je peux vérifier tout ceci avec mon compilateur préféré mais ma question est de savoir si tout ceci est normé ou si je risque d'avoir une mauvaise surprise en changeant de compilo.

Merci à tous pour votre aide!

EDIT : au passage, existe-il un document consultable gratuitement qui donne toutes les priorités entre opérateurs?

http://cppreference.com/wiki/languag...tor_precedence

* est dans la catégorie "right to left" donc on a

Code:

---

d = a*(b*c).

---

Citation:

---

Envoyé par Aleph69

=
1. est-ce toujours vrai si a,b,c,d sont des objets quelconques et * et + ont été surchargés?

---

Oui malheureusement on ne peut pas modifier la priorité des opérateurs. (ou heureusement... selon le point de vue :p)

Citation:

---

Envoyé par Goten

Oui malheureusement on ne peut pas modifier la priorité des opérateurs. (ou heureusement... selon le point de vue :p)

---

Je suis assez perplexe sur le "malheureusement" anéfé :D

Citation:

---

Envoyé par oxyde356

Je suis assez perplexe sur le "malheureusement" anéfé :D

---

De même que pour la surcharge des opérateurs (ainsi que d'autres fonctionnalités), ça dépend du point de vue :

• Autoriser la redéfinition des priorités laisse la possibilité de le faire à mauvais escient et de rendre le comportement contre-intuitif.
• Interdire cette redéfinition impose une priorité qui peut ne pas correspondre à la priorité attendue dans certains cas (je pense notamment à l'écriture de DSL).

A partir de là, on a l'opposition "philosophique" classique : doit on interdire ce qui pourrait être mal utilisé (et se débrouiller pour vivre avec ces restrictions) ou faire confiance à l'utilisateur et proposer tous les outils qui pourrait être utile dans quelques rares cas particuliers ?

Je pense qu'il vaut mieux un cadre bien rigoureux que des libertés superflues ^^ (du moins en programmation :P)

Mais la philosophie du C et du C++ est de ne pas avoir de contraintes fortes et en ce sens, ca va un peu contre cette philosophie :) (bien que je sois plus un supporter du "si c'est pas permis explicitement, alors c'est interdit")

Mais en tous cas, c'est un outil impensable au niveau du parsing; cela signifie que durant le parsing il faudrait connaitre les priorités des opérateurs utilisateurs et les types des valeurs que l'on traite, ce serait très complexe (limite impossible).

Oui c'est au programmeur d'être rigoureux, m'enfin il faut que le langage le soit un minimum quand même :P

pas forcément, choisir le bon outil pour la bonne tâche :) si C# est plus rigoureux et plus pertinent pour un projet, tant mieux, si C++ est moins rigoureux mais qu'on a besoin de ces fonctionnalités supplémentaires...

vu qu'il n'y a pas moyen de contenter tout le monde, je prône la différence entre les langages :)
mais c'est vrai aussi que je passe mon temps a mettre des barrières pour que les autres programmeurs ne fassent pas trop de conneries...

Oui enfin là je parle pas de la prog en général je parle dans un langage donné :mrgreen:

Merci à tous pour vos réponses, tout est clair maintenant!