Ordre d'évaluation des conditions dans un if

Bonsoir,

J'ai le problème de compréhension suivant :
Dans un livre consacré au langage C++ il est dit que :
(1)

Code:

---

if ( i < max && (j++ == 10))

---

n'est pas équivalent à :
(2)

Code:

---

1 2	j++; (i < max && (j == 10));

---

"Car l'opérateur && n'évalue son second opérande que lorsque cela est nécessaire. D'où dans la première formulation, l'expression j++ n'est pas évaluée lorsque la condition (i < max) est fausse; elle l'est, en revanche, dans la deuxième formulation."?????
Je ne comprends pas cette explication. Pour moi en (2) les parenthèses forcent l'évaluation de (j) en premier puis l'évaluation de ( i < max) si j est vrai ?...
En (1) même raisonnement ... Donc équivalence ?

Salut,

Ton erreur de compréhension vient que les choses ne se passent pas au niveau des parenthèses, mais bien au niveau de l'opérateur logique &&.

L'opérateur logique && est correspond à un AND "optimisé", et, pour comprendre ce que je vais t'expliquer, rien ne vaut la table de vérité pour AND ;)

si tu mets deux expressions pouvant chacune être représentée par une valeur "vrai" ou "faux" dans une relation AND, tu te trouves confronté à quatre combinaisons possible, avec les résultat suivants:

Code:

---

1 2 3 4 5

expr1 | expr2 | expr1 AND expr2 faux | faux | faux faux | vrai | faux vrai | faux | faux vrai | vrai | vrai

---

Tu constateras que, sur les quatre combinaisons possibles, trois donneront "faux" comme résultat et une seule donnera "vrai" comme résultat.

La combinaison donnant une valeur "vrai" comme résultat est ce que l'on appelle "l'état unique".

Tu constateras aussi que le résultat sera d'office "faux" si la première expression correspond déjà à la valeur "faux".

Si l'on dit que l'opérateur && est un opérateur "optimisé", c'est simplement parce que, s'il arrive à déterminer, après avoir évalué une (ou plusieurs) expression(s) que le résultat ne sera de toutes façons pas l'état unique, il n'évaluera purement et simplement pas l'expression suivante.

Ainsi, lorsque l'on est confronté à un code proche de

Code:

---

if ( i < max && (j++ == 10))

---

j++ ne sera effectué que si i est bel et bien plus petit que max.

Si i est égal (ou supérieur) à max, la deuxième expression (j++==10) ne sera purement et simplement pas évaluée, et j ne sera donc même pas incrémenté.

Par contre, avec un code proche de

Code:

---

1 2 3

j++; if(i < max && (j == 10))

---

j est incrémenté de manière inconditionnelle (quelle que puisse être la valeur de j ou celle de i) et ce n'est qu'après avoir incrémenté j que l'on va vérifier si i est bel et bien plus petit que max et que j est égal à 10.

Est-ce que cette explication te semble plus claire :question:

Citation:

---

Ton erreur de compréhension vient que les choses ne se passent pas au niveau des parenthèses

---

C'est drôle. J'aurais dit exactement l'inverse.

Si tu as: 0*(12+13+56+4+6+65+9+9+8+7+8), vas-tu te casser le tronc à calculer la somme d'abord?

Non. Tu commences par évaluer le premier facteur du produit, puis le deuxième. Je ne vois pas ce qui peut choquer.

Citation:

---

Envoyé par Flodelarab

C'est drôle. J'aurais dit exactement l'inverse.

Si tu as: 0*(12+13+56+4+6+65+9+9+8+7+8), vas-tu te casser le tronc à calculer la somme d'abord?

Non. Tu commences par évaluer le premier facteur du produit, puis le deuxième. Je ne vois pas ce qui peut choquer.

---

Attention, là, tu parles d'opérateurs mathématique (multiplication et addition).

Je t'avouerai que je ne sais pas du tout comment le compilateur réagit lorsque l'on essaye d'effectuer une multiplication par 0.

Mais je pourrais faire valoir que, dans ton exemple, la somme est purement et simplement une constante de compilation, et que le produit l'est donc aussi.

Le compilateur pourrait tout aussi bien évaluer les expressions dans l'ordre de leur priorité : les parenthèses en premier lieu et terminer par la multiplication, tout comme il pourrait tout aussi bien être "assez intelligent" que pour déterminer que 0 * n'importe quoi sera toujours égal à 0 ;)

Or, le problème est posé avec un opérateur logique (AND), et plus précisément avec un opérateur logique optimisé ;)

[EDIT]Visiblement, tu n'as peut etre pas compris ce que je disais...

Je disais que le code if ( i < max && (j++ == 10)) va d'abord et avant tout évaluer l'expression i<max.

Il obtiendra donc une valeur qui sera égale à true si i est bel et bien plus petit que max et à false si i est plus grand ou égal à max.

Si la valeur est "false", il n'y a aucune raison d'évaluer la deuxième expression, car on sait que la réponse sera toujours false.

Or cette deuxième expression est elle-même composée de deux expression

• j++ d'une part (qui incrémente j)
• j == 10 qui est une expression booléene

il comme il n'évalue pas l'exression complete, aucune de ces deux "sous expression" n'est évaluée, et j n'est donc pas incrémenté ;)

Et puis c'est aussi un comportement imposé par la norme (du moins en C donc en C++ j'imagine que ce n'est pas différent).
C'est ce qui permet d'écrire des choses comme if ( (ptr!=NULL) && (ptr->level<12) ) { ... sans déréférencer un pointeur NULL.

Citation:

---

Envoyé par kwariz

Et puis c'est aussi un comportement imposé par la norme (du moins en C donc en C++ j'imagine que ce n'est pas différent).
C'est ce qui permet d'écrire des choses comme if ( (ptr!=NULL) && (ptr->level<12) ) { ... sans déréférencer un pointeur NULL.

---

Exactement, le comportement de l'opérateur && (tout comme celui de || et de ^ :D) est hérité tout droit du C ;)

Non mais ça vient simplement du fait que les opérations sont effectuées de gauche à droite.

Prenons un opérateur non optimisé pour nous en convaincre:

Code:

---

1 2	i = -1; if ( valeurAbsolueQuiModifiei(i) == ( i++ ) )

---

J'imagine que i vaut 2 à la fin

Code:

---

1 2	i = -1; if ( ( i++ ) == valeurAbsolueQuiModifiei(i) )

---

J'imagine que i vaut 0 à la fin


Y a pas de questions de parenthèses, d'optimisation ou de C.

Je m’immisce un peu dans le monde C++, mais en C la norme garantit un point de séquence après l'évaluation de la première opérande des opérateurs &&, || et , mais pas des autres comme ==. Une expression comme if ( valeurAbsolueQuiModifiei(i) == ( i++ ) ) a un comportement indéfini.
Mais c'est à vérifier.

Citation:

---

Envoyé par Flodelarab

Non mais ça vient simplement du fait que les opérations sont effectuées de gauche à droite.

Prenons un opérateur non optimisé pour nous en convaincre:

Code:

---

1 2	i = -1; if ( valeurAbsolueQuiModifiei(i) == ( i++ ) )

---

J'imagine que i vaut 2 à la fin

Code:

---

1 2	i = -1; if ( ( i++ ) == valeurAbsolueQuiModifiei(i) )

---

J'imagine que i vaut 0 à la fin


Y a pas de questions de parenthèses, d'optimisation ou de C.

---

Heu c'est certain qu'ils sont evalue dans cet ordre la? Je pensais que c'etait non-definis et qu'on ne peut pas se baser sur l'ordre d'evaluation dans ce genre de cas...

Citation:

---

Envoyé par kwariz

Je m’immisce un peu dans le monde C++, mais en C la norme garantit un point de séquence après l'évaluation de la première opérande des opérateurs &&, || et , mais pas des autres comme ==. Une expression comme if ( valeurAbsolueQuiModifiei(i) == ( i++ ) ) a un comportement indéfini.
Mais c'est à vérifier.

---

Il me semblait aussi que c'etait le cas en C++...

Citation:

---

Envoyé par Flodelarab

Non mais ça vient simplement du fait que les opérations sont effectuées de gauche à droite.

Prenons un opérateur non optimisé pour nous en convaincre:

Code:

---

1 2	i = -1; if ( valeurAbsolueQuiModifiei(i) == ( i++ ) )

---

J'imagine que i vaut 2 à la fin

Code:

---

1 2	i = -1; if ( ( i++ ) == valeurAbsolueQuiModifiei(i) )

---

J'imagine que i vaut 0 à la fin


Y a pas de questions de parenthèses, d'optimisation ou de C.

---

Là, tu n'as qu'une expression booléenne, ce qui est encore différent!

Pour que tu puisse obtenir un résultat booléen, (qui puisse décider si tu rentre ou non dans le cas "vrai"), il faudra fatalement que tu évalues les deux parties de l'expression "=="

Or, ce dont on parle c'est d'une expression booléenne qui vérifie deux condition

1. i < max d'une part ET
2. j++ == 10 d'autre part

ou, si tu préfères, tu te retrouve avec un AST proche de

Code:

---

1 2 3 4 5 6 7 8

AND / \ / \ < == / \ / \ i max += 10 / \ j 1

---

Quand on va rencontrer le AND, on va, effectivement passer en priorité dans la branche gauche.

Là, on se rend compte que l'on a affaire à une nouvelle expression (i < max) qui nous renvoie une valeur booléenne.

C'est chouette, parce que AND permet justement choisir de passer (ou non) quelque part en fonction des valeurs booléennes.

Si c'était "juste" un AND non optimisé, (comme cela pourrait l'être sous la forme de (if (i<max & (j++ == 10)) ) on passerait d'office dans la branche droite du AND, et l' on remarquerait que l'expression j++ == 10 (qui est aussi une expression booléenne vu qu'elle utilise l'opérateur == ) est en fait composé d'une autre expression (j++ que j'ai traduit un peut honteusement par j+=1 ) qu'il faudrait évaluer afin de pouvoir donner le résultat.

Mais nous sommes face à l'opérateur optimisé &&!!!

L'optimisation qu'il est capable de faire est qu'il peut "laisser tomber toute expression qui ne pourrait en aucun cas modifier le résultat final".

Alors, bien sur, il va commencer par l'expression de gauche!

Et il y aura, comme je l'ai dit, deux solutions:
Soit i est effectivement plus petit que max, et, dans ce cas là, il devra vérifier l'expression de droite.

Soit i est plus grand ou égal à max, et, dans ce cas, le résultat de l'expression suivante ne changera plus rien au résultat final : ce sera de toutes manière faux.

Dans ce deuxième cas, il décide donc de ne pas évaluer l'expression de droite, et donc, la sous expression (traduite par j+=1) n'est pas effectuée ;)

Citation:

---

Envoyé par Flodelarab

Non mais ça vient simplement du fait que les opérations sont effectuées de gauche à droite.

Prenons un opérateur non optimisé pour nous en convaincre:

Code:

---

1 2	i = -1; if ( valeurAbsolueQuiModifiei(i) == ( i++ ) )

---

J'imagine que i vaut 2 à la fin

Code:

---

1 2	i = -1; if ( ( i++ ) == valeurAbsolueQuiModifiei(i) )

---

J'imagine que i vaut 0 à la fin


Y a pas de questions de parenthèses, d'optimisation ou de C.

---

Non, l'ordre d'évaluation entre les deux opérandes de l'opérateur == n'est pas garanti, les deux choix possible (en plus du souci de séquencement évoqué par kwariz).

Bonsoir,

Je met mon grain de sel, mais c'est un principe d'évaluation des "AND" assez répandu non? (Short Circuit Evaluation)

Dans ( expression booléenne A ) && ( expression booléenne B ), ( expression booléenne B ) n'est évaluée que si ( expression booléenne A ) est vraie?

C'est pas garanti par la norme ça, car optimisation activée ou non, le code suivant à le même comportement :

Code:

---

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

#include <iostream>   bool verifieEtEcrit( int i ){ std::cout << "[" << i << "]" << std::endl; return i < 5 ; }   int main( int argc, char* argv[] ){ bool resultat = true ; for ( size_t i = 0; i < 10; i++ ){ resultat = resultat && verifieEtEcrit( i ) ; } std::cout << "resultat : " << (resultat?"true":"false") << std::endl; return 0 ; }

---

=>

[0]
[1]
[2]
[3]
[4]
[5]
resultat : false

Edit : Discussion stackoverflow sur le sujet

Ton code montre exactement ce qui est dit plus haut.
A partir de i=6 resultat vaut déjà false et la 2° partie du test sensée affichée la valeur de i n'est plus exécutée. ;)

A toute fin utile, je précise que le AND non optimisé est l’opérateur binaire &.
Tout comme le || est un OR optimisé également : si le premier est à true, le deuxième n'est pas évalué.
Et un bel exemple de cohérence du langage : le OR non optimisé est l'opérateur binaire |.

Citation:

---

Envoyé par Bousk

Ton code montre exactement ce qui est dit plus haut.
A partir de i=6 resultat vaut déjà false et la 2° partie du test sensée affichée la valeur de i n'est plus exécutée. ;)

---

Mille excuses, j'avais l'impression qu'on mélangeait le problème avec d'autres.

Accessoirement, je viens de découvrir le terme "Short Circuit Evaluation" alors je partage le mot clé ;)

Citation:

---

A toute fin utile, je précise que le AND non optimisé est l'operateur binaire &.

---

C'est utile pour bibi oui :oops:

Citation:

---

Envoyé par germinolegrand

A toute fin utile, je précise que le AND non optimisé est l’opérateur binaire &.
Tout comme le || est un OR optimisé également : si le premier est à true, le deuxième n'est pas évalué.
Et un bel exemple de cohérence du langage : le OR non optimisé est l'opérateur binaire |.

---

Ce n'est pas tant une différence optimisé/non optimisé qu'une finalité différente :

• && et || pour des opérations logiques entre expressions
• & et | pour des opérations binaires sur des valeurs

Même si on peut effectivement utiliser assez facilement la seconde famille à la place de la première (l'inverse n'est pas aussi vrai).

On parle aussi de "lazy evaluation" (ou "évaluation paresseuse").

Citation:

---

Envoyé par germinolegrand

A toute fin utile, je précise que le AND non optimisé est l’opérateur binaire &.
Tout comme le || est un OR optimisé également : si le premier est à true, le deuxième n'est pas évalué.
Et un bel exemple de cohérence du langage : le OR non optimisé est l'opérateur binaire |.

---

Je ne suis pas tout à fait d'accord, c'est un raccourcit trop facile.

& n'est pas un "AND non-optimisé", c'est un ET bit à bit alors que AND travaille sur les valeurs des opérandes converties en valeurs booléennes en effet :

0x000101 & 0x100000 = 0x000000 = false
0x000101 && 0x100000 = true && true = true

@Neckara: merci d'avoir explicité les propos de @gl qui lui même mettait la loupe sur le "opérateur binaire" de mon message :mouarf: !

Même si ce n'est pas leur raison d'être fondamentale, dans le contexte qui nous intéresse ici ces opérateurs binaires sont les seuls à pouvoir remplir la fonction de AND et OR non paresseux. S'ils n'étaient pas utilisables pour cet usage, nul doute que les standards C/C++ proposerait d'autres opérateurs pour le remplir !

Citation:

---

Envoyé par bretus

Bonsoir,

Je met mon grain de sel, mais c'est un principe d'évaluation des "AND" assez répandu non? (Short Circuit Evaluation)

Dans ( expression booléenne A ) && ( expression booléenne B ), ( expression booléenne B ) n'est évaluée que si ( expression booléenne A ) est vraie?

C'est pas garanti par la norme ça, car optimisation activée ou non, le code suivant à le même comportement :

---

Si c'est garanti par la norme.

C'est ce qui t'assure de ne pas te manger une erreur de segmentation avec un code proche de

Code:

---

1 2 3 4

while( pointer!=nullptr && pointer->next = nullptr){ pointer = pointer->next; /*... */ }

---

Si ce n'était pas garanti au niveau de la norme, tu devrais écrire un code proche de

Code:

---

1 2 3 4 5 6

while(pointer != nullptr){ if(pointer->next != nullptr-{ pointer = pointer->next; /* ... */ } }

---

pour ne pas risquer de te manger une erreur de segmentation ;)

Citation:

---

Envoyé par Neckara

Je ne suis pas tout à fait d'accord, c'est un raccourcit trop facile.

& n'est pas un "AND non-optimisé", c'est un ET bit à bit alors que AND travaille sur les valeurs des opérandes converties en valeurs booléennes en effet :

0x000101 & 0x100000 = 0x000000 = false
0x000101 && 0x100000 = true && true = true

---

Le & bit-à-bit, appliqué sur des "vrais" Booléens (comme les retours d'opérateurs de comparaison) correspond bel et bien à un AND non-optimisé. Mais ça nécessite une vraie comparaison, donc ces deux codes auront des comportements différents:

Code:

---

1 2	if(ptr & a++ == 42) //Mauvais (résultat du test varie selon valeur de ptr) cout << "blabla" << endl;

---

Code:

---

1 2	if(ptr!=0 & a++ == 42) //Bon cout << "blabla" << endl;

---

Mais dans les deux cas, a++ == 42 sera évalué.

A ma connaissance, les seuls opérateurs concernés par l'évaluation paresseuses sont le ternaire ?: et les opérateurs logiques && et ||.

Je crois me souvenir, mais cela demande confirmation, que ca n'est plus vrai une fois qu'ils ne sont pas redéfinis.

Citation:

---

Envoyé par leternel

Je crois me souvenir, mais cela demande confirmation, que ca n'est plus vrai une fois qu'ils ne sont pas redéfinis.

---

En fait, il est impossible de redéfinir les opérateur logiques && , || et ? : .

On peut redéfinir les opérateurs logiques binaires, &, |, ^, ~ et leur composé d'affectation, mais pas les versions "optimisée" ;)

Pour le ternaire, je savais, mais je croyais que les seuls impossibles était:

• les opérateurs de types: sizeof, typeid, alignof, truc_cast<T>
• les opérateurs de nom: les accesseurs de membres (. et .*) et la portée (::)
• le ternaire (?:)
• l'adressage (& unaire)
• noexcept

Citation:

---

Operator Overloading
Syntax
type operator op ( params ) ;
Explanation
<type> is/are the type(s) of the variables.
<op> is the particular operator (e.g. +, +=, <<, >>, &&, ||, %, etc.).
<params> is/are the name(s) of the required parameters (depends on the operator).

Restrictions
You cannot create new operators such as ** or &|.
Not all operators can be overloaded
Some operators can only be overloaded as non-static class members
Short-circuit evaluation doesn't work with overloaded operators

---

source: cppreference.com

Donc on peut bien les redéfinir, ils perdent simplement leur propriété de court-circuit :).

Code:

---

bool operator&&(<T> const& a, <S> const& b)

---

Effectivement, c'est bien ce que j'ai vérifié.
Ce brave g++ n'a pas rallé pour un code tel que:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class Boolean { bool value; public: Boolean(bool b):value(b){} Boolean operator&&(Boolean const&) const; Boolean operator||(Boolean const&) const; Boolean& operator|=(Boolean const&); Boolean operator|(Boolean const&) const; Boolean operator!() const; };

---

Citation:

---

Envoyé par leternel

Pour le ternaire, je savais, mais je croyais que les seuls impossibles était:

• les opérateurs de nom: l'accesseur (.) et la portée (:: )

---

La portée, ca semble logique, mais l'accesseur... je ne sais plus vraiment.

Je sais que l'on peut redéfinir l'opérateur de déréférencement, ( * ) et l'accesseur depuis un pointeur ( -> ) car c'est ce que font les itérateurs.

Pour l'accesseur "simple", je suis pris d'un doute ;)

Je suis très sûr pour celui-là.
On ne peut pas, "parce que" tu ne pourrais pas spécifier les arguments de la fonction. l'operateur attendent certes une variables à gauche, mais un identifieur lexical à droite (un nom de membre, pour être précis).

La raison est que le variable->membre est implémenté par récurrence:
si variable est un pointeur, retourner (*variable).membre.
si variable est n'importe-quoi d'autre, retourner (variable.operator->())->membre


En fait, j'en ai omis un autre, le déréférencement de pointeur membre ".*" (je ne suis sur ni du nom, ni de l'usage)

Les cinq que j'ai appris sont ?:, ., .*, sizeof et ::.

Citation:

---

Envoyé par leternel

Je suis très sûr pour celui-là.
On ne peut pas, "parce que" tu ne pourrais pas spécifier les arguments de la fonction. l'operateur attendent certes une variables à gauche, mais un identifieur lexical à droite (un nom de membre, pour être précis).

La raison est que le variable->membre est implémenté par récurrence:
si variable est un pointeur, retourner (*variable).membre.
si variable est n'importe-quoi d'autre, retourner (variable.operator->())->membre


En fait, j'en ai omis un autre, le déréférencement de pointeur membre ".*" (je ne suis sur ni du nom, ni de l'usage)

Les cinq que j'ai appris sont ?:, ., .*, sizeof et ::.

---

en fait, maintenant que tu le dis, c'est logique :D

L'accesseur simple n'est pas redéfinissable.

Les seuls opérateurs non surchargeables sont les suivants :
Adressage : x.y
Adressage d'un pointeur sur membre : x.*y
Ternaire : x ? y : z
Résolution de portée : x::y
Résolution de portée pour les pointeurs sur membre : x::*y
Taille : sizeof(x)
Identification de type : typeid(x)

Tous les autres sont parfaitement candidats à la surcharge.

As-tu essayé de surcharger dynamic_cast<Tau>, où Tau serait une classe de ton goût? ou l'adressage d'une variable quelconque?

Je vous renvoie (comme d'habitude) le lien habituel qui parle des opérateurs, leur précédence et surcharge.

erf, j'avais zappé les cast C++ et les opérateurs C++11...