Discussion :

[christian79]

Bonsoir,

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

Code :

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

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

n'est pas équivalent à :
(2)

Code :

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

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 ?

[koala01]

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 :

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

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 :

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

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 :

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

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

[Flodelarab]

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.

[koala01]

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é

[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.

[koala01]

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 ^ ) est hérité tout droit du C

[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 :

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

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

J'imagine que i vaut 2 à la fin

Code :

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

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.

[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.

[Klaim]

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 :

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

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

J'imagine que i vaut 2 à la fin

Code :

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

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...

[Klaim]

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++...

[koala01]

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 :

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

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

J'imagine que i vaut 2 à la fin

Code :

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

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 :

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

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

[gl]

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 :

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

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

J'imagine que i vaut 2 à la fin

Code :

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

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).

[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 :

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 <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

[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.

[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 |.

[bretus]

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é

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

C'est utile pour bibi oui

[gl]

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).

[ternel]

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

[Neckara]

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

[germinolegrand]

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

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 !