Develop Reference

Short circuiting logical operators, precedence, and evaluation order? [duplicate]

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.

Does Java have an operator precedence table? [duplicate]

Misunderstanding Java operator precedence is a source of frequently asked questions and subtle errors. I was intrigued to learn that even the Java Language Specification says, "It is recommended that code not rely crucially on this specification." JLS §15.7 Preferring clear to clever, are there any useful guidelines in this area?
As noted here, this problem should be studied in the context of Evaluation Order, detailed here. Here are a number of resources on the topic:
JLS Operators
JLS Precedence
JLS Evaluation Order
What are the rules for evaluation order in Java?
Java Glossary
Princeton
Oracle Tutorial
Conversions and Promotions
Usenet discussion
Additions or corrections welcome.

As far as the "Real World" is concerned, it's probably fair to say:
enough programmers know that multiplication/division take precedence over addition/subtraction, as is mathematically the convention
hardly any programmers can remember any of the other rules of precedence
So, apart from the specific case of */ vs +-, I'd really just use brackets to explicitly define the precedence intended.

Another related source of bugs is how rounding errors accumulate. Not an operator precedence order issue per se, but a source of surprise when you get a different result after rearranging operands in an arithmetically-equivalent way. Here's a sun.com version of David Goldberg's What Every Computer Scientist Should Know About Floating-Point Arithmetic.

The quote (from the Java Language Specification §15.7) should be read in the context of Evaluation Order. As discussed here, that section concerns evaluation order, which is not related to operator precedence (or associativity).
Precedence and associativity influence the structure of the expression tree (i.e. which operators act on which operands), while "evaluation order" merely influences the order in which the expression tree is traversed when the expression is evaluated. Evaluation order (or "traversal order") does not have any effect unless some sub-expressions have side-effects that affect the result (or side-effects) of other sub-expressions.
For example, if x==1 initially, the expression ++x/++x would evaluate as 2/3 (which evaluates to 0) since Java has left-to-right evaluation order. Had evaluation order in Java been right-to-left, x would have been incremented twice before the numerator is evaluated, and the expression would have evaluated as 3/2 (which evaluates to 1). Had evaluation order been undefined, the expression could have evaluated to either of these results.
The quote in question, together with its context, ...
The Java programming language guarantees that the operands of
operators appear to be evaluated in a specific evaluation order,
namely, from left to right.
It is recommended that code not rely crucially on this specification.
Code is usually clearer when each expression contains at most one side
effect, as its outermost operation
...discourages the reader from depending on the left-to-rightness of Java's evaluation order (as in the example above). It does not encourage unnecessary parentheses.
Edit: Resource: Java operator precedence table that also serves as an index into sections of the JLS containing the syntactic grammar from which each precedence level is inferred.

Also, don't forget the logical && and || are shortcut operators, avoid something like:
sideeffect1() || sideeffect2()
If sideeffect1() is evaluating to true, sideeffect2() isn't going to be executed. The same goes for && and false. This is not entirely related to precendence, but in these extreme cases the assiociativity can also be an important aspect that normally is really irrelevant (at least as far as i am concerned)

The JLS does not give an explicit operator precedence table; it is implied when the JLS describes various operators. For example, the grammar for ShiftExpression is this:
ShiftExpression:
AdditiveExpression
ShiftExpression << AdditiveExpression
ShiftExpression >> AdditiveExpression
ShiftExpression >>> AdditiveExpression
This means that additive operators (+ and -) have a higher precedence than the left-associative shift operators (<<, >> and >>>).

It seems to me that the truth of this is that 'most programmers' think 'most other programmers' don't know or can't remember operator precedence, so they indulge in what is indulgently called 'defensive programming' by 'inserting the missing parentheses', just to 'clarify' that. Whether remembering this third-grade stuff is a real problem is another question. It just as arguable that all this is a complete waste of time and if anything makes things worse. My own view is that redundant syntax is to be avoided wherever possible, and that computer programmers should know the language they are programming in, and also perhaps raise their expectations of their colleagues.

How does expression evaluation order differ between C++ and Java?

I've had my brain wrinkled from trying to understand the examples on this page:
http://answers.yahoo.com/question/index?qid=20091103170907AAxXYG9
More specifically this code:
int j = 4;
cout << j++ << j << ++j << endl;
gives an output: 566
Now this makes sense to me if the expression is evaluated right to left, however in Java a similar expression:
int j = 4;
System.out.print("" + (j++) + (j) + (++j));
gives an output of: 456
Which is more intuitive because this indicates it's been evaluated left to right. Researching this across various sites, it seems that with C++ the behaviour differs between compilers, but I'm still not convinced I understand. What's the explanation for this difference in evaluation between Java and C++? Thanks SO.

When an operation has side effects, C++ relies on sequence points rule to decide when side effects (such as increments, combined assignments, etc.) have to take effect. Logical and-then/or-else (&& and ||) operators, ternary ? question mark operators, and commas create sequence points; +, -, << and so on do not.
In contrast, Java completes side effects before proceeding with further evaluation.
When you use an expression with side effects multiple times in the absence of sequence points, the resulting behavior is undefined in C++. Any result is possible, including one that does not make logical sense.

Java guarantees that the operands of operators appear to be evaluated in a specific evaluation order, namely, from left to right. The left-hand operand of a binary operator appears to be fully evaluated before any part of the right-hand operand is evaluated. Java also guarantees that every operand of an operator (except the conditional operators &&, ||, and ?:) appears to be fully evaluated before any part of the operation itself is performed. See Java language specification §15.7 for more details.
C++, on the other hand, happily let's you get away with undefined behavior if the expression is ambiguous because language itself doesn't guarantee any order of evaluation of sub-expressions. See Sequence Point for more details.

In C++ the order of evalulations of subexpressions isn't left-to-right nor right-to-left. It is undefined.

Are the &, |, ^ bitwise operators or logical operators?

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

Bitwise operator and single ampersand [duplicate]

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.