&& = et || = opérateurs

Question

Doublons possibles:
Why doesn't Java have compound assignment versions of the conditional-and and conditional-or operators? (&&=, ||=)
Why does a “&&=” Operator not exist?

Aujourd'hui, au travail, j'ai écrit la lettre de crédit suivante (les identités réelles de b et b1 sont confidentielles:

b &&= b1; // meaning b = b && b1; 

Je l'ai regardé pour un couple de secondes et s'est rendu compte qu'il n'existe pas un tel opérateur. Juste pour être sûr, j'ai cliqué sur compiler et il a échoué. Pour être sûr que j'ai consulté la norme.

Y a-t-il des raisons spécifiques à l'absence de tels opérateurs? Je pense à certains:

1. b &&= b1 et b = b && b1 peuvent ne pas être équivalent à cause de l'évaluation de court-circuit de & &.
2. & & = est laid
3. & & = est rarement nécessaire

Je ne prétends pas que ce serait très utile d'avoir ces opérateurs, non. Je ne prétends pas non plus que l'une quelconque ou la totalité des trois raisons ci-dessus ne suffisent pas à ne pas créer cet opérateur. Ma question est la suivante: y a-t-il une raison beaucoup plus sérieuse que je supervise?

Answer 1

Je ne sais pas pourquoi la question et certaines des réponses mentionnent le comportement de court-circuit des opérateurs logiques correspondants en tant que problème potentiel.

Il n'y a absolument aucun problème lié aux courts-circuits avec la définition des opérateurs &&= et ||=. Ils doivent être définis uniformément avec += et d'autres opérateurs similaires, ce qui signifie que a &&= b doit être équivalent à a = a && b, mais a étant évalué une seule fois en version &&=. Cela signifie à son tour que b n'est pas évalué du tout si a est à l'origine zéro. Facile. Donc, la seule raison pour laquelle ils n'existent pas dans la langue est, bien, "juste parce que".

Answer 2

EDIT: Langue incorrecte, mais applique toujours

Je suis d'accord avec vos trois raisons, bien qu'il y ait un scénario où je l'ai déploré le manque de cet opérateur, lors de l'écriture des routines de désérialisation personnalisé. Dans quelques cas où un objet incorrectement sérialisé n'était pas vraiment "exceptionnel" (et pour éviter une surcharge d'exception en C# pour des échecs très communs), j'utiliserais des valeurs de retour booléennes pour indiquer si une opération de désérialisation était réussie.

Ce code est tout à fait théorique, et Nested1, Nested2 et Nested3 sont tous struct:

public struct ComplexStruct 
{ 
    private Nested1 nested1; 
    private Nested2 nested2; 
    private Nested3[] nested3; 

    public bool Read(Reader reader) 
    { 
     bool ret = true; 
     int nested3Length = 0; 

     ret &&= nested1.Read(reader); 
     ret &&= nested2.Read(reader); 
     ret &&= reader.ReadInt32(ref nested3Length); 

     for(int i = 0; (ret && i < nested3Length); i++) 
     { 
      ret &&= nested3[i].Read(reader); 
     } 

     return ret; 
    } 
} 

Answer 3

Je les ai toujours désiré aussi bien. Je doute que la laideur soit en soi le facteur déterminant, le comportement de court-circuit est le meilleur argument contre eux que j'ai entendu jusqu'ici.

Un autre facteur contribuant est que C est conçu pour fonctionner près du métal, à peu près tous les opérateurs correspondent directement à une instruction dans les architectures majeures. Je ne pense pas qu'il existe une instruction sur x86, PPC, etc qui implémente directement b &&= b1;

Answer 4

Personnellement, je voterais pour la première raison que vous avez choisie. Les opérateurs booléens ont des sémantiques de court-circuit, ce qui rendrait certaines situations vraiment nettes si elles étaient traduites en opérateurs d'affectation. Soit vous ne les faites plus court-circuiter, soit vous créez un étrange opérateur d'assignation "optionnel" (faites les choses sur la droite et n'attribuez dans le résultat que si la valeur sur le LHS est déjà non nulle). D'une manière ou d'une autre, vous créeriez des bugs subtils car les gens s'attendraient à l'autre comportement.

Answer 5

La plus grande raison pour laquelle les opérateurs n'existent pas est probablement que K & R n'a pas pensé à un moyen attrayant de les définir. J'ai aussi parfois voulu un opérateur -> = (ptr -> = next serait équivalent à ptr = ptr-> quoi que ce soit).

Un problème que je pense avec & & = est que ce n'est pas évident que des éléments suivants serait le plus utile, ou qu'il est censé être:

 
    if (lhs && rhs) lhs = 1; else lhs = 0; 
    if (!rhs) lhs = 0; else lhs = !(!lhs)); 
    if (lhs && !rhs) lhs = 0; 
    if (!rhs) lhs = 0; 

La première variante est le plus clairement suggéré par la syntaxe, mais de d'un point de vue pratique, si aucun terme n'est nul, il serait souvent plus utile de laisser le côté gauche seul que de le mettre à "1".

BTW, j'ai souvent souhaité une variation de l'opérateur virgule qui permettrait d'évaluer le côté gauche, enregistrer la valeur, puis évaluer le côté droit et retourner la valeur du côté gauche. Equivalent à:

 
int foo(int p1, int p2) return p1; 

sauf applicable à tout type (p2 n'a pas besoin d'être du même type que p1, et pourrait être vide), et avec un ordre d'évaluation de gauche à droite garanti. Serait très utile pour des choses comme l'indexation post-incrément avec une étape non-unité, par exemple, arr [ptr ~, ptr + = 2]; ou pour certains types d'opérations d'échange de données, par exemple var1 = (var2 ~, var2 = var1);

Answer 6

Parce que le résultat de a && b est toujours 0 ou 1, je pense que l'interprétation de ce ne serait sans ambiguïté pour le type C99 _Bool. Comme cela n'existait pas au moment de la création de C, cet opérateur n'était alors pas inclus. Et de nos jours, personne n'ajoute facilement un autre opérateur à C, car cela aurait un impact sur tous les analyseurs existants.