Execution order of f1() + f2()*f3() expression and operator precedence in JLSWhat are the rules for...
What would cause a nuclear power plant to break down after 2000 years, but not sooner?
Why won't the Republicans use a superdelegate system like the DNC in their nomination process?
Units of measurement, especially length, when body parts vary in size among races
How do I answer an interview question about not meeting deadlines?
Why do so many people play out of turn on the last lead?
rule-based element selection from a matrix
Meaning of だけはわからない
Weird resistor with dots around it on the schematic
Mind ya, it's Homophones Everywhere!
Figure with one caption below and one caption/legend on the side
Are there liquid fueled rocket boosters having coaxial fuel/oxidizer tanks?
Typesetting "hollow slash"
What is the hottest thing in the universe?
Unconventional examples of mathematical modelling
Physical Interpretation of an Overdamped Pendulum
What was the intention with the Commodore 128?
What allows us to use imaginary numbers?
Short comic about alien explorers visiting an abandoned world with giant statues that turn out to be alive but move very slowly
Escape Velocity - Won't the orbital path just become larger with higher initial velocity?
When does The Truman Show take place?
When was "Fredo" an insult to Italian-Americans?
What's a good pattern to calculate a variable only when it is used the first time?
Ignore very specific error message in bash
Is this bar slide trick shown on Cheers real or a visual effect?
Execution order of f1() + f2()*f3() expression and operator precedence in JLS
What are the rules for evaluation order in Java?Java operator precedence guidelinesDoes a finally block always get executed in Java?How can I create an executable JAR with dependencies using Maven?Operator Precedence vs Order of Evaluationc++, evaluating expressions with multiple `&&`s and no operator of lower precedenceWhy don't Java's +=, -=, *=, /= compound assignment operators require casting?Operand evaluation order and associativityJava precedence for multiple + and - operatorsPython `or`, `and` operator precedence exampleWhy is x == (x = y) not the same as (x = y) == x?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
Given an expression f1() + f2()*f3()
with 3 method calls, java evaluates (operands of) addition operation first:
int result = f1() + f2()*f3();
f1 working
f2 working
f3 working
I (wrongly) expected f2()
to be called first, then f3()
, and finally f1()
. Because multiplication shall be evaluated before addition.
So, I don't understand JLS here - what am I missing?
15.7.3. Evaluation Respects Parentheses and Precedence
The Java programming language respects the order of evaluation
indicated explicitly by parentheses and implicitly by operator
precedence.
How exactly operator precedence is respected in this example?
JLS mentions some exceptions in 15.7.5. Evaluation Order for Other Expressions (method invocation expressions (§15.12.4),method reference expressions (§15.13.3)), but I cannot apply any of those exceptions to my example.
I understand that JLS guarantees that operands of a binary operation are evaluated left-to-right. But in my example in order to understand method invocation sequence it is necessary to understand which operation (and both its operands respectively!) is considered first. Am I wrong here - why?
More examples:
int result = f1() + f2()*f3() + f4() + f5()*f6() + (f7()+f8());
proudly produces:
f1 working
f2 working
f3 working
f4 working
f5 working
f6 working
f7 working
f8 working
Which is 100% left-to-right, totally regardless of operator precedence.
int result = f1() + f2() + f3()*f4();
produces:
f1 working
f2 working
f3 working
f4 working
Here the compiler had two options:
f1()+f2()
- addition first
f3()*f4()
- multiplication first
But the "evaluate-left-to-right rule" works here as a charm!
This link implies that in such examples method calls are always evaluated left-to-right regardless of any parenthesis and associativity rules.
java operator-precedence evaluation jls expression-evaluation
add a comment |
Given an expression f1() + f2()*f3()
with 3 method calls, java evaluates (operands of) addition operation first:
int result = f1() + f2()*f3();
f1 working
f2 working
f3 working
I (wrongly) expected f2()
to be called first, then f3()
, and finally f1()
. Because multiplication shall be evaluated before addition.
So, I don't understand JLS here - what am I missing?
15.7.3. Evaluation Respects Parentheses and Precedence
The Java programming language respects the order of evaluation
indicated explicitly by parentheses and implicitly by operator
precedence.
How exactly operator precedence is respected in this example?
JLS mentions some exceptions in 15.7.5. Evaluation Order for Other Expressions (method invocation expressions (§15.12.4),method reference expressions (§15.13.3)), but I cannot apply any of those exceptions to my example.
I understand that JLS guarantees that operands of a binary operation are evaluated left-to-right. But in my example in order to understand method invocation sequence it is necessary to understand which operation (and both its operands respectively!) is considered first. Am I wrong here - why?
More examples:
int result = f1() + f2()*f3() + f4() + f5()*f6() + (f7()+f8());
proudly produces:
f1 working
f2 working
f3 working
f4 working
f5 working
f6 working
f7 working
f8 working
Which is 100% left-to-right, totally regardless of operator precedence.
int result = f1() + f2() + f3()*f4();
produces:
f1 working
f2 working
f3 working
f4 working
Here the compiler had two options:
f1()+f2()
- addition first
f3()*f4()
- multiplication first
But the "evaluate-left-to-right rule" works here as a charm!
This link implies that in such examples method calls are always evaluated left-to-right regardless of any parenthesis and associativity rules.
java operator-precedence evaluation jls expression-evaluation
7
It evaluates the functions in sequential order. It applies the mathematical operators according to PEMDAS.
– Michael Bianconi
yesterday
Step one, figure out method the values in the expression - methods are called LTR. Then figure out the value of the expression - evaluation respects the order of precedence of operators.
– Boris the Spider
yesterday
You should read 15.7.1 and 15.7.2. 15.7.3 just means thatf1()+f1()
won't be replaced with2*f1()
,3.0*x/4.0
won't be replace with(3.0/4.0)*x
, etc...
– Matt Timmermans
yesterday
add a comment |
Given an expression f1() + f2()*f3()
with 3 method calls, java evaluates (operands of) addition operation first:
int result = f1() + f2()*f3();
f1 working
f2 working
f3 working
I (wrongly) expected f2()
to be called first, then f3()
, and finally f1()
. Because multiplication shall be evaluated before addition.
So, I don't understand JLS here - what am I missing?
15.7.3. Evaluation Respects Parentheses and Precedence
The Java programming language respects the order of evaluation
indicated explicitly by parentheses and implicitly by operator
precedence.
How exactly operator precedence is respected in this example?
JLS mentions some exceptions in 15.7.5. Evaluation Order for Other Expressions (method invocation expressions (§15.12.4),method reference expressions (§15.13.3)), but I cannot apply any of those exceptions to my example.
I understand that JLS guarantees that operands of a binary operation are evaluated left-to-right. But in my example in order to understand method invocation sequence it is necessary to understand which operation (and both its operands respectively!) is considered first. Am I wrong here - why?
More examples:
int result = f1() + f2()*f3() + f4() + f5()*f6() + (f7()+f8());
proudly produces:
f1 working
f2 working
f3 working
f4 working
f5 working
f6 working
f7 working
f8 working
Which is 100% left-to-right, totally regardless of operator precedence.
int result = f1() + f2() + f3()*f4();
produces:
f1 working
f2 working
f3 working
f4 working
Here the compiler had two options:
f1()+f2()
- addition first
f3()*f4()
- multiplication first
But the "evaluate-left-to-right rule" works here as a charm!
This link implies that in such examples method calls are always evaluated left-to-right regardless of any parenthesis and associativity rules.
java operator-precedence evaluation jls expression-evaluation
Given an expression f1() + f2()*f3()
with 3 method calls, java evaluates (operands of) addition operation first:
int result = f1() + f2()*f3();
f1 working
f2 working
f3 working
I (wrongly) expected f2()
to be called first, then f3()
, and finally f1()
. Because multiplication shall be evaluated before addition.
So, I don't understand JLS here - what am I missing?
15.7.3. Evaluation Respects Parentheses and Precedence
The Java programming language respects the order of evaluation
indicated explicitly by parentheses and implicitly by operator
precedence.
How exactly operator precedence is respected in this example?
JLS mentions some exceptions in 15.7.5. Evaluation Order for Other Expressions (method invocation expressions (§15.12.4),method reference expressions (§15.13.3)), but I cannot apply any of those exceptions to my example.
I understand that JLS guarantees that operands of a binary operation are evaluated left-to-right. But in my example in order to understand method invocation sequence it is necessary to understand which operation (and both its operands respectively!) is considered first. Am I wrong here - why?
More examples:
int result = f1() + f2()*f3() + f4() + f5()*f6() + (f7()+f8());
proudly produces:
f1 working
f2 working
f3 working
f4 working
f5 working
f6 working
f7 working
f8 working
Which is 100% left-to-right, totally regardless of operator precedence.
int result = f1() + f2() + f3()*f4();
produces:
f1 working
f2 working
f3 working
f4 working
Here the compiler had two options:
f1()+f2()
- addition first
f3()*f4()
- multiplication first
But the "evaluate-left-to-right rule" works here as a charm!
This link implies that in such examples method calls are always evaluated left-to-right regardless of any parenthesis and associativity rules.
java operator-precedence evaluation jls expression-evaluation
java operator-precedence evaluation jls expression-evaluation
edited yesterday
Code Complete
asked 2 days ago
Code CompleteCode Complete
1,0035 silver badges17 bronze badges
1,0035 silver badges17 bronze badges
7
It evaluates the functions in sequential order. It applies the mathematical operators according to PEMDAS.
– Michael Bianconi
yesterday
Step one, figure out method the values in the expression - methods are called LTR. Then figure out the value of the expression - evaluation respects the order of precedence of operators.
– Boris the Spider
yesterday
You should read 15.7.1 and 15.7.2. 15.7.3 just means thatf1()+f1()
won't be replaced with2*f1()
,3.0*x/4.0
won't be replace with(3.0/4.0)*x
, etc...
– Matt Timmermans
yesterday
add a comment |
7
It evaluates the functions in sequential order. It applies the mathematical operators according to PEMDAS.
– Michael Bianconi
yesterday
Step one, figure out method the values in the expression - methods are called LTR. Then figure out the value of the expression - evaluation respects the order of precedence of operators.
– Boris the Spider
yesterday
You should read 15.7.1 and 15.7.2. 15.7.3 just means thatf1()+f1()
won't be replaced with2*f1()
,3.0*x/4.0
won't be replace with(3.0/4.0)*x
, etc...
– Matt Timmermans
yesterday
7
7
It evaluates the functions in sequential order. It applies the mathematical operators according to PEMDAS.
– Michael Bianconi
yesterday
It evaluates the functions in sequential order. It applies the mathematical operators according to PEMDAS.
– Michael Bianconi
yesterday
Step one, figure out method the values in the expression - methods are called LTR. Then figure out the value of the expression - evaluation respects the order of precedence of operators.
– Boris the Spider
yesterday
Step one, figure out method the values in the expression - methods are called LTR. Then figure out the value of the expression - evaluation respects the order of precedence of operators.
– Boris the Spider
yesterday
You should read 15.7.1 and 15.7.2. 15.7.3 just means that
f1()+f1()
won't be replaced with 2*f1()
, 3.0*x/4.0
won't be replace with (3.0/4.0)*x
, etc...– Matt Timmermans
yesterday
You should read 15.7.1 and 15.7.2. 15.7.3 just means that
f1()+f1()
won't be replaced with 2*f1()
, 3.0*x/4.0
won't be replace with (3.0/4.0)*x
, etc...– Matt Timmermans
yesterday
add a comment |
5 Answers
5
active
oldest
votes
You're missing the text immediately under 15.7:
The Java programming language guarantees that the operands of operators appear to be evaluated in a specific evaluation order, namely, from left to right.
The values of the operands of an expression are evaluated before the expression itself. In your specific case, The outermost expression is f1() + [f2() * f3()]
. We must first evaluate f1()
, then we must evaluate f2() * f3()
. Within that, f2()
is evaluated first, then f3()
, then the multiplication (which returns the value for the operand of the +
).
Could you explain how to reconcile §15.7.3 with §15.7?
– John Kugelman
yesterday
Operand evaluation order is clear. The problem is with (binary) operations order (addition operation or multiplication operation shall be first - then operand-evaluation rule makes everything clear).
– Code Complete
yesterday
3
@CodeComplete Your "P.S." still misses the point; you may be confused between compile-time code analysis and runtime evaluation. It might be helpful to draw your expression as a tree and then traverse it in depth-first order (where the leaves are thef?()
expressions).
– chrylis
yesterday
add a comment |
JLS §15.17.2. Evaluate Operands before Operation:
The Java programming language 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.
Thus, f1()
, f2()
and f3()
are evaluated first (left-to-right). Then, operator precedence is applied.
After all, you could observe the execution order in the bytecode, which in my case is:
[...]
INVOKESTATIC Main.f1 ()I
INVOKESTATIC Main.f2 ()I
INVOKESTATIC Main.f3 ()I
IMUL
IADD
Here is how the Expression Tree would look like:
+
/
/
f1 *
/
/
f2 f3
Leaves are evaluated first and the operator precedence is encoded in the tree itself.
add a comment |
Because multiplication shall be evaluated before addition.
As you seem to mean it, that's not a reasonable description of the precedence of multiplication over addition, nor of the effect of section 15.7.3. Precedence says that your expression
f1() + f2()*f3()
is evaluated the same as
f1() + (f2() * f3())
, as opposed to the same as
(f1() + f2()) * f3()
Precedence does not speak to which operand of the +
operator is evaluated first, regardless of the nature of the operands. It speaks instead to what each operand is. This does impact order of evaluation, in that it follows from precedence rules that the result of the multiplication in your original expression must be computed before the result of the addition, but that does not speak directly to the question of when the values of two factors are evaluated relative to each other or to other sub-expressions.
Different rules than the one you quoted are responsible for the order in which the two operands of a +
or *
operator are evaluated -- always the left operand first and the right operand second.
How exactly operator precedence is respected in this example?
The example's output does not convey information about whether precedence -- understood correctly -- is respected. The same output would be observed for both of the two parenthesized alternatives above, and precedence is about which one of those two is equivalent to the original expression.
In an order-of-operations sense, precedence says (only) that the right-hand operand of the addition is f2()*f3()
, which means that product must be computed before the overall sum can be. JLS 15.7.3 isn't saying anything more than or different from that. That that sub-expression is a multiplication has no bearing on its order of evaluation relative to the other operand of the addition operation.
I understand that JLS guarantees that operands of a binary operation are evaluated left-to-right. But in my example in order to
understand method invocation sequence it is necessary to understand
which operation (and both its operands respectively!) is considered
first. Am I wrong here - why?
Yes, you are wrong, and JLS notwithstanding, your examples provide very good evidence for that.
The problem seems to be the "and both its operands respectively" bit. Your idea seems to be roughly that Java should look through the expression, find all the multiplication operations and fully evaluate them, including their operands, and only afterward go back and do the same for the addition operations. But that is not required to observe precedence, and it is not consistent with the left-to-right evaluation order of addition operations, and it would make Java code much harder for humans to write or read.
Let's consider your longer example:
int result = f1() + f2()*f3() + f4() + f5()*f6() + (f7()+f8());
Evaluation proceeds as follows:
f1()
is evaluated first, because it is the left operand of the first operation, and the the operation's operands must be evaluated left-to-right
f2()
is evaluated next, because it is part of the right operand to the addition (whose turn it is to be evaluated), and specifically the left operand of the multiplication
f3()
is evaluated next, because the multiplication sub-expression to which it belongs is being evaluated, and it is the right operand of that multiplication. Precedence affects the order of operations here by establishing that in fact it is the product that is being evaluated. If that were not so, then instead, the result off2()
would be added to the result off1()
at this point, beforef3()
was computed.- the product of
f2()
andf3()
is computed, in accordance with the precedence of multiplication over addition. - The sum of (previously evaluated)
f1()
andf2()*f3()
is computed. This arises from a combination of precedence of*
over+
already discussed, and the left-to-right associativity of+
, which establishes that the sum is the left operand of the next addition operation, and therefore must be evaluated before that operation's right operand.
f4()
is evaluated, because it is the right operand of the addition operation being evaluated at that point.- The second sum is computed. This is again because of the left-to-right associativity of
+
, and the left-to-right evaluation order of the next addition operation.
f5()
thenf6()
then their product is evaluated. This is completely analogous to the case off2()*f3()
, and thus is another exercise of operator precedence.- the result of
f5()*f6()
, as the right-hand operand of an addition operation, is added to the left-hand operand. This is again analogous to previous steps.
f7()
is evaluated.
Because of the parentheses,f8()
is evaluated next, and then its sum with the previously-determined result of evaluatingf7()
, and then that result is added to the preceding result to complete the computation. Without the parentheses, the order would be different: the result off7()
would be added to the preceding result, thenf8()
computed, then that result added.
1
I see what you're saying (and largely agree with it), but the OP's spec quote really is about the fact that multiplication is evaluated before addition, so you can't really say that this is "not a reasonable description of" it.
– ruakh
yesterday
1
@ruakh, the comment you're referring to does not responding to the spec quote, but rather to the OP's own (mis-)characterization of what precedence implies in the case of their code. The fact is that precedence and parentheses don't affect evaluation order in the sense that interests the OP. They do it in the sense I've described here.
– John Bollinger
yesterday
Sure, but "multiplication shall be evaluated before addition" is exactly (part of) what the spec is saying here. It's only the OP's follow-on interpretation, that the right-hand-side of the+
should be evaluated before the left-hand-side (because the latter has a*
), that's mistaken.
– ruakh
yesterday
I disagree, @ruakh, and that's the whole point. The spec is not saying that, though its wording is susceptible to such a misinterpretation.
– John Bollinger
yesterday
I have substantially expanded this answer to (I hope) clarify these points.
– John Bollinger
yesterday
|
show 1 more comment
The most useful tip in my opinion was found in this discussion
JLS is not so clear on that - section 15.7 about evaluation speaks only about operands of a single operation, leaving unclear real-life complex cases with many operations combined.
add a comment |
I really don't see a problem here. The method calls are evaluated as they are encountered left to right. This has nothing to do with operator precedence.
Given the following:
int v = f1() + f2() * f3();
System.out.println(v);
public int f1() {
System.out.println("f1()");
return 1;
}
public int f2() {
System.out.println("f2()");
return 2;
}
public int f3() {
System.out.println("f3()");
return 3;
}
}
It prints out
f1()
f2()
f3()
7
Which is exactly what I would expect.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f57501441%2fexecution-order-of-f1-f2f3-expression-and-operator-precedence-in-jls%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
You're missing the text immediately under 15.7:
The Java programming language guarantees that the operands of operators appear to be evaluated in a specific evaluation order, namely, from left to right.
The values of the operands of an expression are evaluated before the expression itself. In your specific case, The outermost expression is f1() + [f2() * f3()]
. We must first evaluate f1()
, then we must evaluate f2() * f3()
. Within that, f2()
is evaluated first, then f3()
, then the multiplication (which returns the value for the operand of the +
).
Could you explain how to reconcile §15.7.3 with §15.7?
– John Kugelman
yesterday
Operand evaluation order is clear. The problem is with (binary) operations order (addition operation or multiplication operation shall be first - then operand-evaluation rule makes everything clear).
– Code Complete
yesterday
3
@CodeComplete Your "P.S." still misses the point; you may be confused between compile-time code analysis and runtime evaluation. It might be helpful to draw your expression as a tree and then traverse it in depth-first order (where the leaves are thef?()
expressions).
– chrylis
yesterday
add a comment |
You're missing the text immediately under 15.7:
The Java programming language guarantees that the operands of operators appear to be evaluated in a specific evaluation order, namely, from left to right.
The values of the operands of an expression are evaluated before the expression itself. In your specific case, The outermost expression is f1() + [f2() * f3()]
. We must first evaluate f1()
, then we must evaluate f2() * f3()
. Within that, f2()
is evaluated first, then f3()
, then the multiplication (which returns the value for the operand of the +
).
Could you explain how to reconcile §15.7.3 with §15.7?
– John Kugelman
yesterday
Operand evaluation order is clear. The problem is with (binary) operations order (addition operation or multiplication operation shall be first - then operand-evaluation rule makes everything clear).
– Code Complete
yesterday
3
@CodeComplete Your "P.S." still misses the point; you may be confused between compile-time code analysis and runtime evaluation. It might be helpful to draw your expression as a tree and then traverse it in depth-first order (where the leaves are thef?()
expressions).
– chrylis
yesterday
add a comment |
You're missing the text immediately under 15.7:
The Java programming language guarantees that the operands of operators appear to be evaluated in a specific evaluation order, namely, from left to right.
The values of the operands of an expression are evaluated before the expression itself. In your specific case, The outermost expression is f1() + [f2() * f3()]
. We must first evaluate f1()
, then we must evaluate f2() * f3()
. Within that, f2()
is evaluated first, then f3()
, then the multiplication (which returns the value for the operand of the +
).
You're missing the text immediately under 15.7:
The Java programming language guarantees that the operands of operators appear to be evaluated in a specific evaluation order, namely, from left to right.
The values of the operands of an expression are evaluated before the expression itself. In your specific case, The outermost expression is f1() + [f2() * f3()]
. We must first evaluate f1()
, then we must evaluate f2() * f3()
. Within that, f2()
is evaluated first, then f3()
, then the multiplication (which returns the value for the operand of the +
).
edited yesterday
answered yesterday
chrylischrylis
53.9k16 gold badges90 silver badges124 bronze badges
53.9k16 gold badges90 silver badges124 bronze badges
Could you explain how to reconcile §15.7.3 with §15.7?
– John Kugelman
yesterday
Operand evaluation order is clear. The problem is with (binary) operations order (addition operation or multiplication operation shall be first - then operand-evaluation rule makes everything clear).
– Code Complete
yesterday
3
@CodeComplete Your "P.S." still misses the point; you may be confused between compile-time code analysis and runtime evaluation. It might be helpful to draw your expression as a tree and then traverse it in depth-first order (where the leaves are thef?()
expressions).
– chrylis
yesterday
add a comment |
Could you explain how to reconcile §15.7.3 with §15.7?
– John Kugelman
yesterday
Operand evaluation order is clear. The problem is with (binary) operations order (addition operation or multiplication operation shall be first - then operand-evaluation rule makes everything clear).
– Code Complete
yesterday
3
@CodeComplete Your "P.S." still misses the point; you may be confused between compile-time code analysis and runtime evaluation. It might be helpful to draw your expression as a tree and then traverse it in depth-first order (where the leaves are thef?()
expressions).
– chrylis
yesterday
Could you explain how to reconcile §15.7.3 with §15.7?
– John Kugelman
yesterday
Could you explain how to reconcile §15.7.3 with §15.7?
– John Kugelman
yesterday
Operand evaluation order is clear. The problem is with (binary) operations order (addition operation or multiplication operation shall be first - then operand-evaluation rule makes everything clear).
– Code Complete
yesterday
Operand evaluation order is clear. The problem is with (binary) operations order (addition operation or multiplication operation shall be first - then operand-evaluation rule makes everything clear).
– Code Complete
yesterday
3
3
@CodeComplete Your "P.S." still misses the point; you may be confused between compile-time code analysis and runtime evaluation. It might be helpful to draw your expression as a tree and then traverse it in depth-first order (where the leaves are the
f?()
expressions).– chrylis
yesterday
@CodeComplete Your "P.S." still misses the point; you may be confused between compile-time code analysis and runtime evaluation. It might be helpful to draw your expression as a tree and then traverse it in depth-first order (where the leaves are the
f?()
expressions).– chrylis
yesterday
add a comment |
JLS §15.17.2. Evaluate Operands before Operation:
The Java programming language 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.
Thus, f1()
, f2()
and f3()
are evaluated first (left-to-right). Then, operator precedence is applied.
After all, you could observe the execution order in the bytecode, which in my case is:
[...]
INVOKESTATIC Main.f1 ()I
INVOKESTATIC Main.f2 ()I
INVOKESTATIC Main.f3 ()I
IMUL
IADD
Here is how the Expression Tree would look like:
+
/
/
f1 *
/
/
f2 f3
Leaves are evaluated first and the operator precedence is encoded in the tree itself.
add a comment |
JLS §15.17.2. Evaluate Operands before Operation:
The Java programming language 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.
Thus, f1()
, f2()
and f3()
are evaluated first (left-to-right). Then, operator precedence is applied.
After all, you could observe the execution order in the bytecode, which in my case is:
[...]
INVOKESTATIC Main.f1 ()I
INVOKESTATIC Main.f2 ()I
INVOKESTATIC Main.f3 ()I
IMUL
IADD
Here is how the Expression Tree would look like:
+
/
/
f1 *
/
/
f2 f3
Leaves are evaluated first and the operator precedence is encoded in the tree itself.
add a comment |
JLS §15.17.2. Evaluate Operands before Operation:
The Java programming language 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.
Thus, f1()
, f2()
and f3()
are evaluated first (left-to-right). Then, operator precedence is applied.
After all, you could observe the execution order in the bytecode, which in my case is:
[...]
INVOKESTATIC Main.f1 ()I
INVOKESTATIC Main.f2 ()I
INVOKESTATIC Main.f3 ()I
IMUL
IADD
Here is how the Expression Tree would look like:
+
/
/
f1 *
/
/
f2 f3
Leaves are evaluated first and the operator precedence is encoded in the tree itself.
JLS §15.17.2. Evaluate Operands before Operation:
The Java programming language 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.
Thus, f1()
, f2()
and f3()
are evaluated first (left-to-right). Then, operator precedence is applied.
After all, you could observe the execution order in the bytecode, which in my case is:
[...]
INVOKESTATIC Main.f1 ()I
INVOKESTATIC Main.f2 ()I
INVOKESTATIC Main.f3 ()I
IMUL
IADD
Here is how the Expression Tree would look like:
+
/
/
f1 *
/
/
f2 f3
Leaves are evaluated first and the operator precedence is encoded in the tree itself.
edited yesterday
answered yesterday
Oleksandr PyrohovOleksandr Pyrohov
10.9k4 gold badges45 silver badges76 bronze badges
10.9k4 gold badges45 silver badges76 bronze badges
add a comment |
add a comment |
Because multiplication shall be evaluated before addition.
As you seem to mean it, that's not a reasonable description of the precedence of multiplication over addition, nor of the effect of section 15.7.3. Precedence says that your expression
f1() + f2()*f3()
is evaluated the same as
f1() + (f2() * f3())
, as opposed to the same as
(f1() + f2()) * f3()
Precedence does not speak to which operand of the +
operator is evaluated first, regardless of the nature of the operands. It speaks instead to what each operand is. This does impact order of evaluation, in that it follows from precedence rules that the result of the multiplication in your original expression must be computed before the result of the addition, but that does not speak directly to the question of when the values of two factors are evaluated relative to each other or to other sub-expressions.
Different rules than the one you quoted are responsible for the order in which the two operands of a +
or *
operator are evaluated -- always the left operand first and the right operand second.
How exactly operator precedence is respected in this example?
The example's output does not convey information about whether precedence -- understood correctly -- is respected. The same output would be observed for both of the two parenthesized alternatives above, and precedence is about which one of those two is equivalent to the original expression.
In an order-of-operations sense, precedence says (only) that the right-hand operand of the addition is f2()*f3()
, which means that product must be computed before the overall sum can be. JLS 15.7.3 isn't saying anything more than or different from that. That that sub-expression is a multiplication has no bearing on its order of evaluation relative to the other operand of the addition operation.
I understand that JLS guarantees that operands of a binary operation are evaluated left-to-right. But in my example in order to
understand method invocation sequence it is necessary to understand
which operation (and both its operands respectively!) is considered
first. Am I wrong here - why?
Yes, you are wrong, and JLS notwithstanding, your examples provide very good evidence for that.
The problem seems to be the "and both its operands respectively" bit. Your idea seems to be roughly that Java should look through the expression, find all the multiplication operations and fully evaluate them, including their operands, and only afterward go back and do the same for the addition operations. But that is not required to observe precedence, and it is not consistent with the left-to-right evaluation order of addition operations, and it would make Java code much harder for humans to write or read.
Let's consider your longer example:
int result = f1() + f2()*f3() + f4() + f5()*f6() + (f7()+f8());
Evaluation proceeds as follows:
f1()
is evaluated first, because it is the left operand of the first operation, and the the operation's operands must be evaluated left-to-right
f2()
is evaluated next, because it is part of the right operand to the addition (whose turn it is to be evaluated), and specifically the left operand of the multiplication
f3()
is evaluated next, because the multiplication sub-expression to which it belongs is being evaluated, and it is the right operand of that multiplication. Precedence affects the order of operations here by establishing that in fact it is the product that is being evaluated. If that were not so, then instead, the result off2()
would be added to the result off1()
at this point, beforef3()
was computed.- the product of
f2()
andf3()
is computed, in accordance with the precedence of multiplication over addition. - The sum of (previously evaluated)
f1()
andf2()*f3()
is computed. This arises from a combination of precedence of*
over+
already discussed, and the left-to-right associativity of+
, which establishes that the sum is the left operand of the next addition operation, and therefore must be evaluated before that operation's right operand.
f4()
is evaluated, because it is the right operand of the addition operation being evaluated at that point.- The second sum is computed. This is again because of the left-to-right associativity of
+
, and the left-to-right evaluation order of the next addition operation.
f5()
thenf6()
then their product is evaluated. This is completely analogous to the case off2()*f3()
, and thus is another exercise of operator precedence.- the result of
f5()*f6()
, as the right-hand operand of an addition operation, is added to the left-hand operand. This is again analogous to previous steps.
f7()
is evaluated.
Because of the parentheses,f8()
is evaluated next, and then its sum with the previously-determined result of evaluatingf7()
, and then that result is added to the preceding result to complete the computation. Without the parentheses, the order would be different: the result off7()
would be added to the preceding result, thenf8()
computed, then that result added.
1
I see what you're saying (and largely agree with it), but the OP's spec quote really is about the fact that multiplication is evaluated before addition, so you can't really say that this is "not a reasonable description of" it.
– ruakh
yesterday
1
@ruakh, the comment you're referring to does not responding to the spec quote, but rather to the OP's own (mis-)characterization of what precedence implies in the case of their code. The fact is that precedence and parentheses don't affect evaluation order in the sense that interests the OP. They do it in the sense I've described here.
– John Bollinger
yesterday
Sure, but "multiplication shall be evaluated before addition" is exactly (part of) what the spec is saying here. It's only the OP's follow-on interpretation, that the right-hand-side of the+
should be evaluated before the left-hand-side (because the latter has a*
), that's mistaken.
– ruakh
yesterday
I disagree, @ruakh, and that's the whole point. The spec is not saying that, though its wording is susceptible to such a misinterpretation.
– John Bollinger
yesterday
I have substantially expanded this answer to (I hope) clarify these points.
– John Bollinger
yesterday
|
show 1 more comment
Because multiplication shall be evaluated before addition.
As you seem to mean it, that's not a reasonable description of the precedence of multiplication over addition, nor of the effect of section 15.7.3. Precedence says that your expression
f1() + f2()*f3()
is evaluated the same as
f1() + (f2() * f3())
, as opposed to the same as
(f1() + f2()) * f3()
Precedence does not speak to which operand of the +
operator is evaluated first, regardless of the nature of the operands. It speaks instead to what each operand is. This does impact order of evaluation, in that it follows from precedence rules that the result of the multiplication in your original expression must be computed before the result of the addition, but that does not speak directly to the question of when the values of two factors are evaluated relative to each other or to other sub-expressions.
Different rules than the one you quoted are responsible for the order in which the two operands of a +
or *
operator are evaluated -- always the left operand first and the right operand second.
How exactly operator precedence is respected in this example?
The example's output does not convey information about whether precedence -- understood correctly -- is respected. The same output would be observed for both of the two parenthesized alternatives above, and precedence is about which one of those two is equivalent to the original expression.
In an order-of-operations sense, precedence says (only) that the right-hand operand of the addition is f2()*f3()
, which means that product must be computed before the overall sum can be. JLS 15.7.3 isn't saying anything more than or different from that. That that sub-expression is a multiplication has no bearing on its order of evaluation relative to the other operand of the addition operation.
I understand that JLS guarantees that operands of a binary operation are evaluated left-to-right. But in my example in order to
understand method invocation sequence it is necessary to understand
which operation (and both its operands respectively!) is considered
first. Am I wrong here - why?
Yes, you are wrong, and JLS notwithstanding, your examples provide very good evidence for that.
The problem seems to be the "and both its operands respectively" bit. Your idea seems to be roughly that Java should look through the expression, find all the multiplication operations and fully evaluate them, including their operands, and only afterward go back and do the same for the addition operations. But that is not required to observe precedence, and it is not consistent with the left-to-right evaluation order of addition operations, and it would make Java code much harder for humans to write or read.
Let's consider your longer example:
int result = f1() + f2()*f3() + f4() + f5()*f6() + (f7()+f8());
Evaluation proceeds as follows:
f1()
is evaluated first, because it is the left operand of the first operation, and the the operation's operands must be evaluated left-to-right
f2()
is evaluated next, because it is part of the right operand to the addition (whose turn it is to be evaluated), and specifically the left operand of the multiplication
f3()
is evaluated next, because the multiplication sub-expression to which it belongs is being evaluated, and it is the right operand of that multiplication. Precedence affects the order of operations here by establishing that in fact it is the product that is being evaluated. If that were not so, then instead, the result off2()
would be added to the result off1()
at this point, beforef3()
was computed.- the product of
f2()
andf3()
is computed, in accordance with the precedence of multiplication over addition. - The sum of (previously evaluated)
f1()
andf2()*f3()
is computed. This arises from a combination of precedence of*
over+
already discussed, and the left-to-right associativity of+
, which establishes that the sum is the left operand of the next addition operation, and therefore must be evaluated before that operation's right operand.
f4()
is evaluated, because it is the right operand of the addition operation being evaluated at that point.- The second sum is computed. This is again because of the left-to-right associativity of
+
, and the left-to-right evaluation order of the next addition operation.
f5()
thenf6()
then their product is evaluated. This is completely analogous to the case off2()*f3()
, and thus is another exercise of operator precedence.- the result of
f5()*f6()
, as the right-hand operand of an addition operation, is added to the left-hand operand. This is again analogous to previous steps.
f7()
is evaluated.
Because of the parentheses,f8()
is evaluated next, and then its sum with the previously-determined result of evaluatingf7()
, and then that result is added to the preceding result to complete the computation. Without the parentheses, the order would be different: the result off7()
would be added to the preceding result, thenf8()
computed, then that result added.
1
I see what you're saying (and largely agree with it), but the OP's spec quote really is about the fact that multiplication is evaluated before addition, so you can't really say that this is "not a reasonable description of" it.
– ruakh
yesterday
1
@ruakh, the comment you're referring to does not responding to the spec quote, but rather to the OP's own (mis-)characterization of what precedence implies in the case of their code. The fact is that precedence and parentheses don't affect evaluation order in the sense that interests the OP. They do it in the sense I've described here.
– John Bollinger
yesterday
Sure, but "multiplication shall be evaluated before addition" is exactly (part of) what the spec is saying here. It's only the OP's follow-on interpretation, that the right-hand-side of the+
should be evaluated before the left-hand-side (because the latter has a*
), that's mistaken.
– ruakh
yesterday
I disagree, @ruakh, and that's the whole point. The spec is not saying that, though its wording is susceptible to such a misinterpretation.
– John Bollinger
yesterday
I have substantially expanded this answer to (I hope) clarify these points.
– John Bollinger
yesterday
|
show 1 more comment
Because multiplication shall be evaluated before addition.
As you seem to mean it, that's not a reasonable description of the precedence of multiplication over addition, nor of the effect of section 15.7.3. Precedence says that your expression
f1() + f2()*f3()
is evaluated the same as
f1() + (f2() * f3())
, as opposed to the same as
(f1() + f2()) * f3()
Precedence does not speak to which operand of the +
operator is evaluated first, regardless of the nature of the operands. It speaks instead to what each operand is. This does impact order of evaluation, in that it follows from precedence rules that the result of the multiplication in your original expression must be computed before the result of the addition, but that does not speak directly to the question of when the values of two factors are evaluated relative to each other or to other sub-expressions.
Different rules than the one you quoted are responsible for the order in which the two operands of a +
or *
operator are evaluated -- always the left operand first and the right operand second.
How exactly operator precedence is respected in this example?
The example's output does not convey information about whether precedence -- understood correctly -- is respected. The same output would be observed for both of the two parenthesized alternatives above, and precedence is about which one of those two is equivalent to the original expression.
In an order-of-operations sense, precedence says (only) that the right-hand operand of the addition is f2()*f3()
, which means that product must be computed before the overall sum can be. JLS 15.7.3 isn't saying anything more than or different from that. That that sub-expression is a multiplication has no bearing on its order of evaluation relative to the other operand of the addition operation.
I understand that JLS guarantees that operands of a binary operation are evaluated left-to-right. But in my example in order to
understand method invocation sequence it is necessary to understand
which operation (and both its operands respectively!) is considered
first. Am I wrong here - why?
Yes, you are wrong, and JLS notwithstanding, your examples provide very good evidence for that.
The problem seems to be the "and both its operands respectively" bit. Your idea seems to be roughly that Java should look through the expression, find all the multiplication operations and fully evaluate them, including their operands, and only afterward go back and do the same for the addition operations. But that is not required to observe precedence, and it is not consistent with the left-to-right evaluation order of addition operations, and it would make Java code much harder for humans to write or read.
Let's consider your longer example:
int result = f1() + f2()*f3() + f4() + f5()*f6() + (f7()+f8());
Evaluation proceeds as follows:
f1()
is evaluated first, because it is the left operand of the first operation, and the the operation's operands must be evaluated left-to-right
f2()
is evaluated next, because it is part of the right operand to the addition (whose turn it is to be evaluated), and specifically the left operand of the multiplication
f3()
is evaluated next, because the multiplication sub-expression to which it belongs is being evaluated, and it is the right operand of that multiplication. Precedence affects the order of operations here by establishing that in fact it is the product that is being evaluated. If that were not so, then instead, the result off2()
would be added to the result off1()
at this point, beforef3()
was computed.- the product of
f2()
andf3()
is computed, in accordance with the precedence of multiplication over addition. - The sum of (previously evaluated)
f1()
andf2()*f3()
is computed. This arises from a combination of precedence of*
over+
already discussed, and the left-to-right associativity of+
, which establishes that the sum is the left operand of the next addition operation, and therefore must be evaluated before that operation's right operand.
f4()
is evaluated, because it is the right operand of the addition operation being evaluated at that point.- The second sum is computed. This is again because of the left-to-right associativity of
+
, and the left-to-right evaluation order of the next addition operation.
f5()
thenf6()
then their product is evaluated. This is completely analogous to the case off2()*f3()
, and thus is another exercise of operator precedence.- the result of
f5()*f6()
, as the right-hand operand of an addition operation, is added to the left-hand operand. This is again analogous to previous steps.
f7()
is evaluated.
Because of the parentheses,f8()
is evaluated next, and then its sum with the previously-determined result of evaluatingf7()
, and then that result is added to the preceding result to complete the computation. Without the parentheses, the order would be different: the result off7()
would be added to the preceding result, thenf8()
computed, then that result added.
Because multiplication shall be evaluated before addition.
As you seem to mean it, that's not a reasonable description of the precedence of multiplication over addition, nor of the effect of section 15.7.3. Precedence says that your expression
f1() + f2()*f3()
is evaluated the same as
f1() + (f2() * f3())
, as opposed to the same as
(f1() + f2()) * f3()
Precedence does not speak to which operand of the +
operator is evaluated first, regardless of the nature of the operands. It speaks instead to what each operand is. This does impact order of evaluation, in that it follows from precedence rules that the result of the multiplication in your original expression must be computed before the result of the addition, but that does not speak directly to the question of when the values of two factors are evaluated relative to each other or to other sub-expressions.
Different rules than the one you quoted are responsible for the order in which the two operands of a +
or *
operator are evaluated -- always the left operand first and the right operand second.
How exactly operator precedence is respected in this example?
The example's output does not convey information about whether precedence -- understood correctly -- is respected. The same output would be observed for both of the two parenthesized alternatives above, and precedence is about which one of those two is equivalent to the original expression.
In an order-of-operations sense, precedence says (only) that the right-hand operand of the addition is f2()*f3()
, which means that product must be computed before the overall sum can be. JLS 15.7.3 isn't saying anything more than or different from that. That that sub-expression is a multiplication has no bearing on its order of evaluation relative to the other operand of the addition operation.
I understand that JLS guarantees that operands of a binary operation are evaluated left-to-right. But in my example in order to
understand method invocation sequence it is necessary to understand
which operation (and both its operands respectively!) is considered
first. Am I wrong here - why?
Yes, you are wrong, and JLS notwithstanding, your examples provide very good evidence for that.
The problem seems to be the "and both its operands respectively" bit. Your idea seems to be roughly that Java should look through the expression, find all the multiplication operations and fully evaluate them, including their operands, and only afterward go back and do the same for the addition operations. But that is not required to observe precedence, and it is not consistent with the left-to-right evaluation order of addition operations, and it would make Java code much harder for humans to write or read.
Let's consider your longer example:
int result = f1() + f2()*f3() + f4() + f5()*f6() + (f7()+f8());
Evaluation proceeds as follows:
f1()
is evaluated first, because it is the left operand of the first operation, and the the operation's operands must be evaluated left-to-right
f2()
is evaluated next, because it is part of the right operand to the addition (whose turn it is to be evaluated), and specifically the left operand of the multiplication
f3()
is evaluated next, because the multiplication sub-expression to which it belongs is being evaluated, and it is the right operand of that multiplication. Precedence affects the order of operations here by establishing that in fact it is the product that is being evaluated. If that were not so, then instead, the result off2()
would be added to the result off1()
at this point, beforef3()
was computed.- the product of
f2()
andf3()
is computed, in accordance with the precedence of multiplication over addition. - The sum of (previously evaluated)
f1()
andf2()*f3()
is computed. This arises from a combination of precedence of*
over+
already discussed, and the left-to-right associativity of+
, which establishes that the sum is the left operand of the next addition operation, and therefore must be evaluated before that operation's right operand.
f4()
is evaluated, because it is the right operand of the addition operation being evaluated at that point.- The second sum is computed. This is again because of the left-to-right associativity of
+
, and the left-to-right evaluation order of the next addition operation.
f5()
thenf6()
then their product is evaluated. This is completely analogous to the case off2()*f3()
, and thus is another exercise of operator precedence.- the result of
f5()*f6()
, as the right-hand operand of an addition operation, is added to the left-hand operand. This is again analogous to previous steps.
f7()
is evaluated.
Because of the parentheses,f8()
is evaluated next, and then its sum with the previously-determined result of evaluatingf7()
, and then that result is added to the preceding result to complete the computation. Without the parentheses, the order would be different: the result off7()
would be added to the preceding result, thenf8()
computed, then that result added.
edited yesterday
answered yesterday
John BollingerJohn Bollinger
95.7k8 gold badges48 silver badges91 bronze badges
95.7k8 gold badges48 silver badges91 bronze badges
1
I see what you're saying (and largely agree with it), but the OP's spec quote really is about the fact that multiplication is evaluated before addition, so you can't really say that this is "not a reasonable description of" it.
– ruakh
yesterday
1
@ruakh, the comment you're referring to does not responding to the spec quote, but rather to the OP's own (mis-)characterization of what precedence implies in the case of their code. The fact is that precedence and parentheses don't affect evaluation order in the sense that interests the OP. They do it in the sense I've described here.
– John Bollinger
yesterday
Sure, but "multiplication shall be evaluated before addition" is exactly (part of) what the spec is saying here. It's only the OP's follow-on interpretation, that the right-hand-side of the+
should be evaluated before the left-hand-side (because the latter has a*
), that's mistaken.
– ruakh
yesterday
I disagree, @ruakh, and that's the whole point. The spec is not saying that, though its wording is susceptible to such a misinterpretation.
– John Bollinger
yesterday
I have substantially expanded this answer to (I hope) clarify these points.
– John Bollinger
yesterday
|
show 1 more comment
1
I see what you're saying (and largely agree with it), but the OP's spec quote really is about the fact that multiplication is evaluated before addition, so you can't really say that this is "not a reasonable description of" it.
– ruakh
yesterday
1
@ruakh, the comment you're referring to does not responding to the spec quote, but rather to the OP's own (mis-)characterization of what precedence implies in the case of their code. The fact is that precedence and parentheses don't affect evaluation order in the sense that interests the OP. They do it in the sense I've described here.
– John Bollinger
yesterday
Sure, but "multiplication shall be evaluated before addition" is exactly (part of) what the spec is saying here. It's only the OP's follow-on interpretation, that the right-hand-side of the+
should be evaluated before the left-hand-side (because the latter has a*
), that's mistaken.
– ruakh
yesterday
I disagree, @ruakh, and that's the whole point. The spec is not saying that, though its wording is susceptible to such a misinterpretation.
– John Bollinger
yesterday
I have substantially expanded this answer to (I hope) clarify these points.
– John Bollinger
yesterday
1
1
I see what you're saying (and largely agree with it), but the OP's spec quote really is about the fact that multiplication is evaluated before addition, so you can't really say that this is "not a reasonable description of" it.
– ruakh
yesterday
I see what you're saying (and largely agree with it), but the OP's spec quote really is about the fact that multiplication is evaluated before addition, so you can't really say that this is "not a reasonable description of" it.
– ruakh
yesterday
1
1
@ruakh, the comment you're referring to does not responding to the spec quote, but rather to the OP's own (mis-)characterization of what precedence implies in the case of their code. The fact is that precedence and parentheses don't affect evaluation order in the sense that interests the OP. They do it in the sense I've described here.
– John Bollinger
yesterday
@ruakh, the comment you're referring to does not responding to the spec quote, but rather to the OP's own (mis-)characterization of what precedence implies in the case of their code. The fact is that precedence and parentheses don't affect evaluation order in the sense that interests the OP. They do it in the sense I've described here.
– John Bollinger
yesterday
Sure, but "multiplication shall be evaluated before addition" is exactly (part of) what the spec is saying here. It's only the OP's follow-on interpretation, that the right-hand-side of the
+
should be evaluated before the left-hand-side (because the latter has a *
), that's mistaken.– ruakh
yesterday
Sure, but "multiplication shall be evaluated before addition" is exactly (part of) what the spec is saying here. It's only the OP's follow-on interpretation, that the right-hand-side of the
+
should be evaluated before the left-hand-side (because the latter has a *
), that's mistaken.– ruakh
yesterday
I disagree, @ruakh, and that's the whole point. The spec is not saying that, though its wording is susceptible to such a misinterpretation.
– John Bollinger
yesterday
I disagree, @ruakh, and that's the whole point. The spec is not saying that, though its wording is susceptible to such a misinterpretation.
– John Bollinger
yesterday
I have substantially expanded this answer to (I hope) clarify these points.
– John Bollinger
yesterday
I have substantially expanded this answer to (I hope) clarify these points.
– John Bollinger
yesterday
|
show 1 more comment
The most useful tip in my opinion was found in this discussion
JLS is not so clear on that - section 15.7 about evaluation speaks only about operands of a single operation, leaving unclear real-life complex cases with many operations combined.
add a comment |
The most useful tip in my opinion was found in this discussion
JLS is not so clear on that - section 15.7 about evaluation speaks only about operands of a single operation, leaving unclear real-life complex cases with many operations combined.
add a comment |
The most useful tip in my opinion was found in this discussion
JLS is not so clear on that - section 15.7 about evaluation speaks only about operands of a single operation, leaving unclear real-life complex cases with many operations combined.
The most useful tip in my opinion was found in this discussion
JLS is not so clear on that - section 15.7 about evaluation speaks only about operands of a single operation, leaving unclear real-life complex cases with many operations combined.
edited yesterday
answered yesterday
Code CompleteCode Complete
1,0035 silver badges17 bronze badges
1,0035 silver badges17 bronze badges
add a comment |
add a comment |
I really don't see a problem here. The method calls are evaluated as they are encountered left to right. This has nothing to do with operator precedence.
Given the following:
int v = f1() + f2() * f3();
System.out.println(v);
public int f1() {
System.out.println("f1()");
return 1;
}
public int f2() {
System.out.println("f2()");
return 2;
}
public int f3() {
System.out.println("f3()");
return 3;
}
}
It prints out
f1()
f2()
f3()
7
Which is exactly what I would expect.
add a comment |
I really don't see a problem here. The method calls are evaluated as they are encountered left to right. This has nothing to do with operator precedence.
Given the following:
int v = f1() + f2() * f3();
System.out.println(v);
public int f1() {
System.out.println("f1()");
return 1;
}
public int f2() {
System.out.println("f2()");
return 2;
}
public int f3() {
System.out.println("f3()");
return 3;
}
}
It prints out
f1()
f2()
f3()
7
Which is exactly what I would expect.
add a comment |
I really don't see a problem here. The method calls are evaluated as they are encountered left to right. This has nothing to do with operator precedence.
Given the following:
int v = f1() + f2() * f3();
System.out.println(v);
public int f1() {
System.out.println("f1()");
return 1;
}
public int f2() {
System.out.println("f2()");
return 2;
}
public int f3() {
System.out.println("f3()");
return 3;
}
}
It prints out
f1()
f2()
f3()
7
Which is exactly what I would expect.
I really don't see a problem here. The method calls are evaluated as they are encountered left to right. This has nothing to do with operator precedence.
Given the following:
int v = f1() + f2() * f3();
System.out.println(v);
public int f1() {
System.out.println("f1()");
return 1;
}
public int f2() {
System.out.println("f2()");
return 2;
}
public int f3() {
System.out.println("f3()");
return 3;
}
}
It prints out
f1()
f2()
f3()
7
Which is exactly what I would expect.
answered yesterday
WJSWJS
1,9642 gold badges9 silver badges15 bronze badges
1,9642 gold badges9 silver badges15 bronze badges
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f57501441%2fexecution-order-of-f1-f2f3-expression-and-operator-precedence-in-jls%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
7
It evaluates the functions in sequential order. It applies the mathematical operators according to PEMDAS.
– Michael Bianconi
yesterday
Step one, figure out method the values in the expression - methods are called LTR. Then figure out the value of the expression - evaluation respects the order of precedence of operators.
– Boris the Spider
yesterday
You should read 15.7.1 and 15.7.2. 15.7.3 just means that
f1()+f1()
won't be replaced with2*f1()
,3.0*x/4.0
won't be replace with(3.0/4.0)*x
, etc...– Matt Timmermans
yesterday