ANDALSO et ORELSE

[Argorate]

Ter Rowan & niahoo: j'avoue ne pas comprendre du tout^^

Expliquez-moi un seul cas où il est utile d'évaluer l'expression suivante dans son intégralité:

if(false AND true AND true AND true AND {1 millions de conditions plus loin}... AND true) ?

Le principe est justement de ne pas perdre de temps a évaluer une suite de condition logique quand on a trouvé un élément dont on est sur qu'il assure la réponse quelque soit la suite de la condition.

[Sephi-Chan]

Comme il n'y a pas de if en Erlang (du moins, pas comme tu le connais), ça ne doit pas avoir cette forme.

Visiblement, ça peut être lié à des optimisation de compilation. Cf. http://en.m.wikipedia.org/wiki/Short-cir...#section_3

[Ter Rowan]

Ter Rowan & niahoo: j'avoue ne pas comprendre du tout^^

Expliquez-moi un seul cas où il est utile d'évaluer l'expression suivante dans son intégralité:

if(false AND true AND true AND true AND {1 millions de conditions plus loin}... AND true) ?

Le principe est justement de ne pas perdre de temps a évaluer une suite de condition logique quand on a trouvé un élément dont on est sur qu'il assure la réponse quelque soit la suite de la condition.

Tu ne regardes que le resultat la

Mais tu peux très bien lancer deux actions en parallèle et evaluer ensuite le couple de résultats

[Argorate]

Je ne saisie pas bien le principe, je n'ai jamais travailler avec Erlang, mais bon, je classerais ça dans "cas particularité" ^^

[niahoo]

En php tu peux vouloir exécuter 2 actions et voir si la somme booléenne des deux résultats est vraie. Si tu te moques de savoir la quelle a éventuellement échoué et que tu veux lancer les deux dans tous les cas, alors l'opérateur short circuit est inutile dans ce cas.

Mais erlang ou pas ce sera souvent des cas particuliers. Par contre classer un langage complet en cas particulier car tu ne le connais pas, c'est stupide.

Enfin, en erlang pour les opérations triviales ou tu compares des valeurs, le compilateur doit préférer les opérateurs simples car les codes donnés en exemple dans la doc utilisent rarement les short circuits.

[Xenos]

Un exemple de and non-paresseux qui ne soit pas c*n?

Je veux incrémenter $i et $j d'une unité, et si, avant incrémentation, tous deux ne sont pas à 0, j'exécute une action:

Code :

if (($i++) and ($j++))
{
// action
}

Si je ne me trompes pas, $i++ et $j++ incrémentent i et j d'une unité, et renvoie la valeur AVANT incrémentation.

Donc, étude de cas: pour $i=0 et $j=1.

Si l'opérateur est paresseux, alors $i++ est évaluée, $i vaut donc 1, et ($i++) renvoie 0, qui vaut "false" en booléen. Donc, l'expression n'est pas évaluée plus en avant: l'action dans le if n'est pas exécutée, et $i=1 et $j=1.
Si l'opérateur est non-paresseux, alors $i++ est évaluée, $i vaut donc 1 et ($i++) renvoie 0 qui vaut false en booléen. Le membre suivant est alors évalué. Donc $j vaut 2, et ($j++) renvoie 1 qui est évalué à true. L'expression est alors (false and true) et l'action n'est pas effectuée, mais à la sortie du if, cette fois, $i=1 et $j=2!

Donc, la paresse de l'opérateur peut avoir un intérêt, si par exemple, j'avais voulu incrémenter i et j dans tous les cas et ne faire l'action que si les deux, avant incrémentation, étaient non-nuls.

Avec un opérateur paresseux, il faudrait écrire:

Code PHP :

<?php 

$i=0;

$j=1;

$i_old = ($i++);

$j_old = ($j++);

if ($i_old and $j_old)

// action 

[niahoo]

est ce que (($i++) and ($j++)) est équivalent à (++$i and ++$j) ? Parce que là tu utilises le même opérateur, il est toujours paresseux et $j ne sera pas incrémenté si $i++ == 0.

---

Oui donc non, mettre des parenthèses autour de $i++ ne change pas la valeur de retour, c'est toujours la valeur avant l'incrémentation qui est retournée. : http://3v4l.org/BHOrL

---

Pour simuler l'opérateur "pas short circuit" je vois que ça :

<?php



$STOP = 5;

$i = 0;

$j = 5;



while($STOP-- > 0) {



    echo "i = $i ; j = $j\n";



	if ( (bool) $i++  & (bool) $j++ ) {

		echo "2up\n";

    }

}



?>



Output:



i = 0 ; j = 5

i = 1 ; j = 6 <-- $i est bien incrémenté

2up

i = 2 ; j = 7

2up

i = 3 ; j = 8

2up

i = 4 ; j = 9

2up

[Xenos]

Oui, oui, je n'ai jamais dit que j'avais trouvé un trick pour le rendre non-paresseux (l'opérateur de bit & ou | fait ce genre de trick).

En revanche, $i++ n'est pas pareil que ++$i: le premier renvoie la valeur avant incrément, le second renvoie la valeur après (le second est donc théoriquement un peu plus rapide car le PC n'a pas besoin de stocker la valeur avant).

[niahoo]

En revanche, $i++ n'est pas pareil que ++$i: le premier renvoie la valeur avant incrément, le second renvoie la valeur après (le second est donc théoriquement un peu plus rapide car le PC n'a pas besoin de stocker la valeur avant).

Oui c'est pour ça je croyais qu'en ajoutant les parenthèses autour de $i++, soit ($i++), tu pensais obtenir le même comportement que ++$i.

Mais j'avais mal compris ton post tout simplement. (en fait ton dernier bout de code montre la syntaxe avec un éventuel opérateur non paresseux, je croyais que tu pensais que ça marchait).

[Xenos]

D'acc, j'avais du mal m'exprimer.

Je mets souvent plus de parenthèses que nécessaire... Je sais pas si c'est une mauvaise habitude ^^ En tous cas, c'est une habitude qui m'est restée depuis un langage de script de jeu (Medal of Honor), qui requérait un taux de parenthèse assez impressionnant O.o