> Hello,
> I have a question about evaluation order.
[quoted text clipped - 5 lines]
> 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 - 14 Nov 2005 20:05 GMT
>http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.7
15.7.4 Argument Lists are Evaluated Left-to-Right

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Nan Li - 14 Nov 2005 20:14 GMT
> > Hello,
> > I have a question about evaluation order.
[quoted text clipped - 16 lines]
>
> - Oliver
Thank you. This is better than C++ and I should have checked the spec
first.
Nan
Roedy Green - 15 Nov 2005 06:51 GMT
>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.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
"." - 14 Nov 2005 22:41 GMT
> > Hello,
> > I have a question about evaluation order.
[quoted text clipped - 9 lines]
> 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).

Signature
Send e-mail to: darrell dot grainger at utoronto dot ca
Oliver Wong - 15 Nov 2005 15:26 GMT
>> > Hello,
>> > I have a question about evaluation order.
[quoted text clipped - 28 lines]
> 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
Thomas Hawtin - 15 Nov 2005 07:30 GMT
> 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

Signature
Unemployed English Java programmer
http://jroller.com/page/tackline/
> 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[i];

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
> 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.

Signature
Send e-mail to: darrell dot grainger at utoronto dot ca
Roedy Green - 15 Nov 2005 06:54 GMT
>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.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Roedy Green - 15 Nov 2005 06:56 GMT
On Tue, 15 Nov 2005 06:54:40 GMT, Roedy Green
<my_email_is_posted_on_my_website@munged.invalid> wrote, quoted or
indirectly quoted someone who said :
>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
>4) 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.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.