I have a single line code,
int a = 10;
a = ++a * ( ++a + 5);
My expected output was 12 * (11 + 5) = 192 ,but I got 187
Quoting from Eric Lippert's Blog:
The evaluation of an arithmetical expression is controlled by three sets of rules: precedence rules, associativity rules, and order rules.
Precedence rules describe how an underparenthesized expression should be parenthesized when the expression mixes different kinds of operators.
Associativity rules describe how an underparenthesized expression should be parenthesized when the expression has a bunch of the same kind of operator.
Order of evaluation rules describe the order in which each operand in an expression is evaluated.
Higher precedence results in grouping of operands with an operator and doesn't mean the evaluation of operands. It is the order of evaluation which decides sequence of evaluation of sub-expressions in an expression.
As I can see many programmers think that statement
a = ++a * ( ++a + 5);
will invoke undefined behavior. Yes it will invoke UB if there is no guarantee of evaluation order of operands of an operator.
But this is not true in context of java programming language. It has well defined behavior in java (as well as in C#). The Java Language Specification states that:
The Java programming language guarantees that the operands of operators appear to be evaluated in a specific evaluation order, namely, from left to right.
Example 15.7.1-1. Left-Hand Operand Is Evaluated First
In the following program, the
*operator has a left-hand operand that contains an assignment to a variable and a right-hand operand that contains a reference to the same variable. The value produced by the reference will reflect the fact that the assignment occurred first.class Test1 { public static void main(String[] args) { int i = 2; int j = (i=3) * i; System.out.println(j); } }This program produces the output:
9It is not permitted for evaluation of the
*operator to produce 6 instead of 9.
But, still java specification clearly states that not to write such codes:
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, and when code does not depend on exactly which exception arises as a consequence of the left-to-right evaluation of expressions.