En supposant
boolean a = false;
Je me demandais si faire:
a &= b;
est équivalent à
a = a && b; //logical AND, a is false hence b is not evaluated.
ou d’autre part cela signifie
a = a & b; //Bitwise AND. Both a and b are evaluated.
A partir de la spécification de langage Java – 15.26.2 Opérateurs d’assignation composés .
Une expression d’affectation composée de la forme
E1 op= E2
est équivalente àE1 = (T)((E1) op (E2))
, oùT
est le type deE1
, saufE1
n’est évaluée qu’une seule fois.
Donc a &= b;
est équivalent à a = a & b;
.
(Dans certaines utilisations, le typage fait une différence dans le résultat, mais dans celui-ci, b
doit être boolean
et le typage ne fait rien.)
En pratique, il y a peu de différence entre a = a & b;
et a = a && b;
. Si b
est une variable ou une constante, le résultat sera le même pour les deux versions. Il n’y a qu’une différence sémantique lorsque l’évaluation de b
peut avoir des effets secondaires; c’est à dire quand c’est une sous-expression non sortingviale.
Du côté des performances, le compromis est entre le coût d’évaluation de b
et le coût d’un test et d’une twig de la valeur de a
, et l’économie potentielle d’éviter une affectation inutile à a
. L’parsing n’est pas simple, mais à moins que le coût de calcul de b
soit pas négligeable, la différence de performance potentielle entre les deux versions risque d’être trop faible pour être considérée.
voir 15.22.2 du JLS . Pour les opérandes booléens, l’opérateur &
est booléen, pas binary. La seule différence entre &&
et &
pour les opérandes booléens est que pour &&
il est court-circuité (ce qui signifie que le second opérande n’est pas évalué si le premier opérande est évalué à faux).
Donc, dans votre cas, si b
est une primitive, a = a && b
, a = a & b
, et a &= b
font la même chose.
C’est le dernier:
a = a & b;
Je suis tombé sur une situation similaire en utilisant des booléens où je voulais éviter d’appeler b () si un était déjà faux.
Cela a fonctionné pour moi:
a &= a && b()