evaluation order

[Nan Li]

Hello,
I have a question about evaluation order.
Say you have a function call like this: foo( arg1, arg2 ); Is
arg1 evaluated first, or arg2 first?
Another related question is what's the result of " i++ + i++ ".
Is it undefined?

I know in C++, they are both undefined. I am not familiar with the
java side. Thanks a lot.

Nan

 

[Oliver Wong]

Hello,
I have a question about evaluation order.
Say you have a function call like this: foo( arg1, arg2 ); Is
arg1 evaluated first, or arg2 first?
Another related question is what's the result of " i++ + i++ ".
Is it undefined?

I know in C++, they are both undefined. I am not familiar with the
java side. Thanks a lot.

1) Don't write code that depends on the evaluation being done in a
specific order. It's too confusing. Break it up into several statements, so
that the order is clear.
2) They are not undefined. The Java Language Specification is pretty
good with respect to defining the order of evaluation of everything.
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.7
3) You can probably find out the answers by writing short programs and
testing for yourself what the results are.

- Oliver

 

[Roedy Green]

Another related question is what's the result of " i++ + i++ ".
Is it undefined?

my answer is, you should not write code that depends on quirky things
like that. They are very likely to be wrong in a given implementation
since they are so rarely tested. Further they baffle people coming
after you.

Write what you mean clearly.

i += 2;
i *= 2;

p = a;

 

[Roedy Green]

http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.7

15.7.4 Argument Lists are Evaluated Left-to-Right

 

[Nan Li]

1) Don't write code that depends on the evaluation being done in a
specific order. It's too confusing. Break it up into several statements, so
that the order is clear.
2) They are not undefined. The Java Language Specification is pretty
good with respect to defining the order of evaluation of everything.
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.7
3) You can probably find out the answers by writing short programs and
testing for yourself what the results are.

- Oliver

Thank you. This is better than C++ and I should have checked the spec
first.

Nan

 

[.]

Hello,
I have a question about evaluation order.
Say you have a function call like this: foo( arg1, arg2 ); Is
arg1 evaluated first, or arg2 first?
Another related question is what's the result of " i++ + i++ ".
Is it undefined?

Man goes into a doctor's office and says, "Doctor, when I swing my arm
wildly above my head like this [man swings arm wildly] it hurts. Can you
help me with that?" The doctor responds with, "Don't swing your arm like
that."

In other words, don't do it. If I have something like:

int i = 3;
// some code here
foo(++i, i++);

and I want to pass the values 4, 4 then leave i with the value 5 I'd just
change it to:

int i = 3;
// some code here
++i;
foo(i, i);
i++;

It is then obvious that I want to pass i in with the same value, twice.

In other words, use what you know will work. This has a few advantages: 1)
it is more readable, 2) a junior programmer will not get confused, 3) you
have one less thing you need to memorize about the language.

 

[.]

1) Don't write code that depends on the evaluation being done in a
specific order. It's too confusing. Break it up into several statements, so
that the order is clear.
Agreed.

2) They are not undefined. The Java Language Specification is pretty
good with respect to defining the order of evaluation of everything.
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.7

Good to know but not necessary if you follow suggestion #1.

3) You can probably find out the answers by writing short programs and
testing for yourself what the results are.

Without knowing it is well-defined, suggestion #3 is not recommended.

If the behaviour is undefined, it could be consistent for your compiler
but might change for different compilers (different vendors or future
versions from the same vendor).

 

[Roedy Green]

Thank you. This is better than C++ and I should have checked the spec
first.

If you have further problems see
http://mindprod.com/jgloss/precedence.html
which has a link to the JLS.

 

[Roedy Green]

In other words, use what you know will work. This has a few advantages: 1)
it is more readable, 2) a junior programmer will not get confused, 3) you
have one less thing you need to memorize about the language.

4) It will likely to continue to work. If you write code that depends
on quirky things sooner or later your code will run on a platform
where that quirk is not perfectly supported. No one will notice or
care but you. It will be up to you to find the problem, track it
down, get the bug reported and create a workaround.

That is non-Darwinian.

 

[Roedy Green]

4) It will likely to continue to work. If you write code that depends
on quirky things sooner or later your code will run on a platform
where that quirk is not perfectly supported. No one will notice or
care but you. It will be up to you to find the problem, track it
down, get the bug reported and create a workaround.

that should read

 

[Thomas Hawtin]

1) Don't write code that depends on the evaluation being done in a
specific order. It's too confusing. Break it up into several statements, so
that the order is clear.

It can be useful in some situations, particularly with streams, to make
use of Java's well definedness.

2) They are not undefined. The Java Language Specification is pretty
good with respect to defining the order of evaluation of everything.
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.7

It's one of the many aspects of safety that made my switch from C++
enjoyable.

The C++ program I inherited before fell into the trap. Some of the
actual data format was of opposite endianness than documented. The write
code then appears to have been fixed to fix the read code.

3) You can probably find out the answers by writing short programs and
testing for yourself what the results are.

There is a limit on the power of testing. You only find out one
permitted answer (assuming there are no bugs in the system you are
testing, or in the test code). You cannot find out all possible
outcomes. For instance, from 1.5 Object.wait can spontaneously wakeup.
However, you will not discover that from Sun's current J2SE implementation.

Tom Hawtin

 

[Oliver Wong]

Good to know but not necessary if you follow suggestion #1.


Without knowing it is well-defined, suggestion #3 is not recommended.

If the behaviour is undefined, it could be consistent for your compiler
but might change for different compilers (different vendors or future
versions from the same vendor).

Yes, that's why I presented the points in that order; each point assumes
you've read the previous point first.

- Oliver