|| - &&

L’auteur de ce sujet a trouvé une solution à son problème.

Il s’agit d’opérateurs de logique :

  • le premier demande à ce que l’assertion qui le précède soit vraie ou sinon la seconde : bonne_couleur = vert || rouge signifie que bonne_couleur sera vraie si vert est vrai ou si rouge est vrai. Si on n’a ni vert ni rouge alors bonne_couleur est faux.
  • le second demande à ce que les deux assertions soient vraies. Si l’une des deux est fausse alors && est évalué à faux.
+1 -0

le premier demande à ce que l’assertion qui le précède soit vraie ou sinon la seconde

Attention, ce n’est pas exactement ça. Les deux peuvent aussi être vraies, c’est un "ou" dit inclusif. L’exemple des couleurs ne permet pas de s’en rendre compte, mais par exemple si on prend l’assertion lundi || mars, elle sera vraie si lundi est vrai, si mars est vrai ou si les deux sont vrais.

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+1 -0

Je pense que c’était implicite dans son message : si vert est vrai, alors la valeur de rouge n’importe pas.

Ça demande d’être explicité, parce que ce n’est pas une propriété si évidente que ça : qu’est-ce qui se passe si l’évaluation de rouge ne termine pas ?

Édité par Eusèbe

+0 -0

Je pense que c’était implicite dans son message : si vert est vrai, alors la valeur de rouge n’importe pas.

Ça demande d’être explicité, parce que ce n’est pas une propriété si évidente que ça : qu’est-ce qui se passe si l’évaluation de rouge ne termine pas ?

Eusèbe

Si vert est vrai, rouge n’est pas évalué.

Vous aimez le frontend ? Il y a un tas de petites tâches faciles si vous voulez contribuer à ZdS : https://github.com/zestedesavoir/zds-site/issues?q=is%3Aissue+is%3Aopen+label%3AC-Front

+1 -0

Bon les gars faut pas déconner.

En C et dans les languages de la même famille :

  • || est l’opérateur de ’ou’ logique.
  • && est l’opérateur de ’et’ logique

Les tables de vériter du ’et’ et ’ou’ logique sont sur Wikipédia

De plus ! Car oui c’est pas la seule chose.

&& et || ont un comportement court-circuit. C’est à dire que dès que le résultat de l’opération peut être déterminé, le résultat est retourné. Typiquement, l’expression : "0 && foo()" n’évaluera jamais ’foo’ car peut importe ce que retourne foo(), l’expression en générale est fausse.

De même pour ’ou’ : "1 || bar()" n’évaluera jamais bar.

Pour le cas du " foo() || bar()", si foo() ne fini jamais bar n’est pas executé.
Si foo() returne quelque chose qui est évalué a vrai alors bar n’est pas exécuté, l’expression totale vaux vrai.
Si foo() return 0 alors bar() est executé.
Si bar() se termine, l’expression vaut l’évaluation booléen de sa valeur.

Edit: Coupe-circuit :lol: Et personne me fait la remarque ? x’D

Édité par ache

ache.one                 🦹         👾                                🦊

+0 -0

Il faut aussi savoir que && a une priorité plus forte que ||, c’est-à-dire que a && b || c est interprété comme si on avait mis les parenthèses (a && b) || c, et a || b && c comme a || (b && c). La façon de s’en souvenir, c’est de savoir que, dans un certain sens technique, || se comporte comme une somme (une addition) et && comme un produit (une multiplication), donc on donne la priorité à && sur ||, comme on donne la priorité à * sur + (a + b * c est bien a + (b * c)).

(Sur le lien avec la somme et le produit: (a + b) * c est égal à a * c + b * c, et de même (a || b) && c est égal à a && c || b && c).

Édité par gasche

+0 -0

Tu parles de quel langage ? Parce ça, j’imagine que ça peut changer selon l’implémentation.

tleb

Il y a des tags "C" et "C#", donc ceux-là, j’imagine. La priorité de l’opérateur "et" sur l’opérateur "ou" est quand même hyper courante, autant que la priorité de la multiplication sur l’addition. Je ne suis pas sûr qu’il existe des langages où ces opérateurs sont infixes sans que la priorité la plus forte soit donnée au "et".

En revanche, l’évaluation en court-circuit n’est pas toujours dans la spécification du langage, et donc va dépendre de l’implémentation. Typiquement, ce n’est pas le cas en Fortran, mais il n’est pas rare que les compilateurs Fortran ajoutent du court-circuit. Quand tu croyais que le court circuit faisait partie du langage et que l’implémentation change, tu te retrouves avec un bug très chiant à identifier.

Édité par adri1

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte