This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Why do we usually use || not |, what is the difference?
Can I use single ampersand like & instead of a bitwise operator like &&? What kind of differences may arise and is there a specific example to illustrate this issue clearly?
The single & will check both conditions always. The double && will stop after the first condition if it evaluates to false. Using two is a way of "short circuiting" the condition check if you truly only need 1 condition of 2 to be true or false.
An example could be:
if (myString != null && myString.equals("testing"))
If myString is null, the first condition would fail and it would not bother to check the value of it. This is one way you can avoid null pointers.
with & and ¦ both operands are always evaluated
with && and ¦¦ the second operand is only evaluated when it is necessary
Here's a link to a page with a pretty good explanation of how to use these.
Java Quick Reference on Operators
The other answers are correct to an extent, but don't explain the whole thing.
First off, the doubled operators, && and ||, function sort of like nested if statements:
if (expression_a && expression_b) {
do_something;
}
is equivalent to
if (expression_a) {
if (expression_b) {
do_something;
}
}
In both cases, if expression_a evaluates to false then expression_b will not be evaluated -- a feature referred to as "short-circuiting". (The || case is similar but a hair more complicated.)
Additionally, in Java (but not in C/C++) the && and || operators apply only to boolean values -- you cannot use && or || on an int, eg.
The single operators, & and |, on the other hand, are relatively "pure" operators (commutative and associative with respect to themselves), with none of the "short-circuiting" of the double operators. Additionally, they can operate on any integer type -- boolean, char, byte, short, int, long. They perform a bit-by-bit operation -- bit N of the left operand is ANDed or ORed with bit N of the right operand to produce the Nth bit in a result value that is the same bit width as the two operands (after they are widened as appropriate for binary operators). In this regard, their operation with boolean is just the degenerate case (albeit one that is somewhat special-cased).
Normally, one would use only the doubled operators for combining boolean expressions in an if statement. There is no great harm in using the single operators if the boolean expressions involved are "safe" (cannot result in a null pointer exception, eg), but the doubled operators tend to be slightly more efficient and the short-circuiting is often desired (as in if (a != null && a.b == 5), eg), so it's generally wise to cultivate the habit of using the doubled forms. The only thing to beware of is that if you want the second expression to be evaluated (for it's side-effects), the doubled operator will not guarantee this happens.
Related
In JavaScript and Java, the equals operator (== or ===) has a higher precedence than the OR operator (||). Yet both languages (JS, Java) support short-circuiting in if statements:
When we have if(true || anything()), anything() isn't evaluated.
You can also have the following expression: true || foo == getValue()) - for example in an output statement such as console.log(...);, or in an assignment.
Now, according to operator precedence, short-circuiting shouldn't happen, as === = == > || in terms of precedence. (In other words, the comparison should happen first, for which getValue() ought to be called, as the equality check has a higher precedence that the OR comparison.) But it does. getValue() isn't called (as can easily be checked by putting an output statement into its body).
Why (does short circuiting work when the operator precedence says it shouldn't)?
Or am I confusing matters?
Or am I confusing matters?
You are. I think it's much simpler to think about precedence as grouping than ordering. It affects the order of evaluation, but only because it changes the grouping.
I don't know about Javascript for sure, but in Java operands are always evaluated in left-to-right order. The fact that == has higher precedence than || just means that
true || foo == getValue()
is evaluated as
true || (foo == getValue())
rather than
(true || foo) == getValue()
If you just think about precedence in that way, and then consider that evaluation is always left-to-right (so the left operand of || is always evaluated before the right operand, for example) then everything's simple - and getValue() is never evaluated due to short-circuiting.
To remove short-circuiting from the equation, consider this example instead:
A + B * C
... where A, B and C could just be variables, or they could be other expressions such as method calls. In Java, this is guaranteed to be evaluated as:
Evaluate A (and remember it for later)
Evaluate B
Evaluate C
Multiply the results of evaluating B and C
Add the result of evaluating A with the result of the multiplication
Note how even though * has higher precedence than +, A is still evaluated before either B or C. If you want to think of precedence in terms of ordering, note how the multiplication still happens before the addition - but it still fulfills the left-to-right evaluation order too.
According to the language specification, https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.24
At run time, the left-hand operand expression is evaluated first; if the result has type Boolean, it is subjected to unboxing conversion (§5.1.8).
If the resulting value is true, the value of the conditional-or expression is true and the right-hand operand expression is not evaluated.
So if you have a || b==c, it is not interpreted as (a || b) == c, because || has lower precedence, as you found in the tutorial. Instead, it is interpreted as a || (b==c). Now since a is the left side of ||, it is evaluated first.
There is no operator precedence in this case. What you are questioning is like in f(callback) statement the callback function being evaluated even before f. This can not happen.
On the other hand, in JS the || is one of the few places where you can watch laziness at show. The == operand (think as if it is an infix function like in fully functional languages) takes two arguments and the one on the left gets evaluated first. If it resolves to true the second argument doesn't even get evaluated.
I'm just beginning to wrap my head around .equals() vs == , Java's pass-by-copy vs pass-by-reference, etc. And I was wondering if there would ever be a scenario in Java where this would be run infinitely:
while (i != i) {
// infinite loop
}
I have some ideas regarding String objects, Array objects, etc, but can't quite get anything to work. Thanks.
while (Double.NaN != Double.NaN)
I believe this is the "bride of looper" puzzle in the Java Puzzlers book.
See JLS for reference:
Floating-point equality testing is performed in accordance with the rules of the IEEE 754 standard:
If either operand is NaN, then the result of == is false but the
result of != is true. Indeed, the test x!=x is true if and only if the
value of x is NaN. (The methods Float.isNaN and Double.isNaN may also
be used to test whether a value is NaN.)
Firstly I learnt that &, |, ^ are the bitwise operators, and now somebody mentioned them as logical operators with &&, ||, I am completely confused - the same operator has two names? There are already logical operators &&, ||, then why use &, |, ^?
The Java operators &, | and ^ are EITHER bitwise operators OR logical operators ... depending on the types of the operands. If the operands are integers, the operators are bitwise. If they are booleans, then the operators are logical.
And this is not just me saying this. The JLS describes these operators this way too; see JLS 15.22.
(This is just like + meaning EITHER addition OR string concatenation ... depending on the types of the operands. Or just like a "rose" meaning either a flower or a shower attachment. Or "cat" meaning either a furry animal or a UNIX command. Words mean different things in different contexts. And this is true for the symbols used in programming languages too.)
There are already logical operators &&, ||, why use &, |, ^?
In the case of the first two, it is because the operators have different semantics with regards to when / whether the operands get evaluated. The two different semantics are needed in different situations; e.g.
boolean res = str != null && str.isEmpty();
versus
boolean res = foo() & bar(); // ... if I >>need<< to call both methods.
The ^ operator has no short-circuit equivalent because it simply doesn't make sense to have one.
Having a language reference is one thing, interpreting it correctly is another.
We need to interpret things correctly.
Even if Java documented that & is both bitwise and logical, we could make an argument that & really didn't lost its logical-operator-ness mojo since time immemorial, since C. That is, & is first and foremost, an inherently logical operator(albeit a non-short-circuited one at that)
& parses lexically+logically as logical operation.
To prove the point, both of these lines behaves the same, eversince C and upto now(Java, C#, PHP, etc)
if (a == 1 && b)
if (a == 1 & b)
That is, the compiler will interpret those as these:
if ( (a == 1) && (b) )
if ( (a == 1) & (b) )
And even if both variables a and b are both integers. This...
if (a == 1 & b)
... will still be interpereted as:
if ( (a == 1) & (b) )
Hence, this will yield a compilation error on languages which doesn't facilitate integer/boolean duality, e.g. Java and C#:
if (a == 1 & b)
In fact, on the compilation error above, we could even make an argument that & didn't lost its logical(non-short-circuit) operation mojo, and we can conclude that Java continues the tradition of C making the & still a logical operation. Consequently, we could say it's the other way around, i.e. the & can be repurposed as bitwise operation (by applying parenthesis):
if ( a == (1 & b) )
So there we are, in another parallel universe, someone could ask, how to make the & expression become a bitmask operation.
How to make the following compile, I read in JLS that & is a bitwise
operation. Both a and b are integers, but it eludes me why the
following bitwise operation is a compilation error in Java:
if (a == 1 & b)
Or this kind of question:
Why the following didn't compile, I read in JLS that & is a bitwise
operation when both its operands are integers. Both a and b are
integers, but it eludes me why the following bitwise operation is a
compilation error in Java:
if (a == 1 & b)
In fact, I would not be surprised if there's already an existing stackoverflow questions similar to above questions that asked how to do that masking idiom in Java.
To make that logical operation interpretation by the language become bitwise, we have to do this (on all languages, C, Java, C#, PHP, etc):
if ( a == (1 & b) )
So to answer the question, it's not because JLS defined things such way, it's because Java(and other languages inspired by C)'s & operator is for all intents and purposes is still a logical operator, it retained C's syntax and semantics. It's the way it is since C, since time immemorial, since before I was even born.
Things just don't happen by chance, JLS 15.22 didn't happen by chance, there's a deep history around it.
In another parallel universe, where && was not introduced to the language, we will still be using & for logical operations, one might even ask a question today:
Is it true, we can use the logical operator & for bitwise operation?
& doesn't care if its operands are integers or not, booleans or not. It's still a logical operator, a non-short-circuited one. And in fact, the only way to force it to become a bitwise operator in Java(and even in C) is to put parenthesis around it. i.e.
if ( a == (1 & b) )
Think about it, if && was not introduced to C language(and any language who copied its syntax and semantics), anyone could be asking now:
how to use & for bitwise operations?
To sum it up, first and foremost Java & is inherently a logical operator(a non-short-circuited one), it doesn't care about its operands, it will do its business as usual(applying logical operation) even if both operands are integers(e.g. masking idiom). You can only force it to become bitwise operation by applying parenthesis. Java continues the C tradition
If Java's & really is a bitwise operation if its operands(integer 1 and integer variable b on example code below) are both integers, this should compile:
int b = 7;
int a = 1;
if (a == 1 & b) ...
They(& and |) were used for two purposes long time ago, logical operator and bitwise operator. If you'll check out the neonatal C (the language Java was patterned after), & and | were used as logical operator.
But since disambiguating the bitwise operations from logical operations in the same statement is very confusing, it prompted Dennis Ritchie to create a separate operator(&& and ||) for logical operator.
Check the Neonatal C section here: http://cm.bell-labs.com/who/dmr/chist.html
You can still use the bitwise operators as logical operators, its retained operator precedence is the evidence of that. Read out the history of bitwise operator's past life as logical operator on Neonatal C
Regarding the evidence, I made a blog post on comparing the logical operator and bitwise operator. It will be self-evident that the so called bitwise operators are still logical operators if you try contrasting them in an actual program: http://www.anicehumble.com/2012/05/operator-precedence-101.html
I also answered a question related to your question on What is the point of the logical operators in C?
So it's true, bitwise operators are logical operators too, albeit non-short-circuited version of short-circuited logical operators.
Regarding
There are already logical operators &&, ||, then why use &, |, ^?
The XOR can be easily answered, it's like a radio button, only one is allowed, code below returns false. Apology for the contrived code example below, the belief that drinking both beer and milk at the same time is bad was debunked already ;-)
String areYouDiabetic = "Yes";
String areYouEatingCarbohydrate = "Yes";
boolean isAllowed = areYouDiabetic == "Yes" ^ areYouEatingCarbohydrate == "Yes";
System.out.println("Allowed: " + isAllowed);
There's no short-circuit equivalent to XOR bitwise operator, as both sides of the expression are needed be evaluated.
Regarding why the need to use & and | bitwise operators as logical operators, frankly you'll be hard-pressed to find a need to use bitwise operators(a.k.a. non-short-circuit logical operators) as logical operators. A logical operation can be non-short-circuited (by using the bitwise operator, aka non-short-circuited logical operator) if you want to achieve some side effect and make your code compact(subjective), case in point:
while ( !password.isValid() & (attempts++ < MAX_ATTEMPTS) ) {
// re-prompt
}
The above can re-written as the following(removing the parenthesis), and still has exactly the same interpretation as the preceding code.
while ( !password.isValid() & attempts++ < MAX_ATTEMPTS ) {
// re-prompt
}
Removing the parenthesis and yet it still yields the same interpretation as the parenthesized one, can make the logical operator vestige of & more apparent. To run the risk of sounding superfluous, but I have to emphasize that the unparenthesized expression is not interpreted as this:
while ( ( !password.isValid() & attempts++ ) < MAX_ATTEMPTS ) {
// re-prompt
}
To sum it up, using & operator (more popularly known as bitwise operator only, but is actually both bitwise and logical(non-short-circuited)) for non-short-circuit logical operation to achieve side effect is clever(subjective), but is not encouraged, it's just one line of savings effect in exchange for readability.
Example sourced here: Reason for the exsistance of non-short-circuit logical operators
The Java type byte is signed which might be a problem for the bitwise operators. When negative bytes are extended to int or long, the sign bit is copied to all higher bits to keep the interpreted value. For example:
byte b1=(byte)0xFB; // that is -5
byte b2=2;
int i = b1 | b2<<8;
System.out.println((int)b1); // This prints -5
System.out.println(i); // This prints -5
Reason: (int)b1 is internally 0xFFFB and b2<<8 is 0x0200 so i will be 0xFFFB
Solution:
int i = (b1 & 0xFF) | (b2<<8 & 0xFF00);
System.out.println(i); // This prints 763 which is 0x2FB
This seems to be a stupid question since Java does short circuit, but I remembered how Android doesn't quite use Java in the same sense as I assume, so say in this bit of code I wrote:
... code omitted ...
else if (mimeType.equals("application/x-tar")
|| mimeType.equals("application/x-rar-compressed")
|| mimeType.equals("application/stuffit")
|| mimeType.equals("application/zip")
|| mimeType.equals("application/x-gzip"))
...would it be better for me to put the more common things (zip/rar) before the less common things (tarballs/gzip)?
The fact that I wasn't able to find a similar question on SO probably gives me the answer to this, but better safe than sorry.
Short circuiting is supported with ||.
If you are trying to optimize this case you should try putting each value in a static Set and then check to see if typeSet.contains(mimeType).
Yes, the || (conditional-or) operator is a short-circuit operator. To quote the Java Language Specification:
The || operator is like | (§15.22.2), but evaluates its right-hand operand only if the value of its left-hand operand is false. It is syntactically left-associative (it groups left-to-right). It is fully associative with respect to both side effects and result value; that is, for any expressions a, b, and c, evaluation of the expression ((a)||(b))||(c) produces the same result, with the same side effects occurring in the same order, as evaluation of the expression (a)||((b)||(c)).
This question already has answers here:
Closed 11 years ago.
Possible Duplicates:
logical operators in java
What's the difference between | and || in Java?
As the title says, I need to know the difference between & operator and && operator.
Can anyone help me in simple words.
How do they differ from each other?
And which one to be used in a IF statement?
There are in fact three "and" operators:
a && b, with a and b being boolean: evaluate a. If true, evaluate b. If true, result is true. Otherwise, result is false. (I.e. b is not evaluated if a is not true.)
a & b, with a and b being boolean: evaluate both, do logical and (i.e. true only if both are true).
a & b, where a and b are both integral types (int, long, short, char, byte): evaluate a and b, and do a bitwise AND.
The second one can be viewed as a special type of the third one, if one sees boolean as a one-bit integral type ;-)
As the top-level condition of an if-statement you can use the first two, but the first one is most likely useful. (I.e. there are not many cases where you really need the second and the first would do something wrong, but the other way around is more common. In most cases the first is simply a little bit faster.)
If the first result is FALSE, && doesn't evaluate the second result. & does.
&& only evaluates the second expression if the first operation is true. & evaluates both expressions (even if the first expression is false and there is no point in evaluating the second expression). Hence && is a tiny bit faster than & in logical operations. Hence && is also known as short-circuit and.
& can also be used as a bitwise operator in addition to a logical operator. So you can do a 'Bit And' of 2 numbers like for example
int result = 1 & 3; // will evaluate to 1
&& cannot be used as a bit-and operator.
For conditional IF operator, use &&. It is a tiny bit faster than just &.