tags:

views:

181

answers:

6
+4  Q: 

Java vs C output

This might seem simple but it's just stumbled me and my friends...

lets take the following piece of code- in java

//........

int a=10;
a= a-- + a--;
System.out.print("a="+a);
//........

in c

//........

int a=10;
a= a-- + a--;
printf("a= %d",a);
//.......

where in the former case you get output as 19 in C you get it as 18. the logic in c is understandable but in java?

in java if its like

int a=10;
a=a++;

in this case the output is 10.

So what's the logic?

+13  A: 

a = a-- + a-- causes undefined behaviour in C. C does not define which decrement should be evaluated first.

a-- evaluates to the value of a, and after that it decrements a, so in Java a = a-- + a-- evaluates like this:

a = (10, decrement a) + (9, decrement a)

The second operand is 9 because first term caused a to be decremented.

In summary: With that expression, C does not define the evaluation order. Java defines it to be from left to right.

hrnt
If I understand a will be 19. The last decrement isn't effective for the result.
Martijn Courteaux
In Java (I forgot)
Martijn Courteaux
Yes, the last decrement does not show up because right after that we assign 19 to a.
hrnt
+1 Didn't know that Java defines this.
Tronic
+4  A: 

I don't know about Java but in C that line of code doesn't have a return value defined in the standard. Compilers are free to interpret it as they please.

Blindy
A: 

You are post-decrementing. To me, the java result makes more sense.

The first a-- is evaluated as 10, and decrements to 9. 10 is the value of this sub-expression.

The second a-- is evaluated. a is now 9, and decrements to 8. The value of this sub-expression is 9.

So, it becomes 10 + 9 = 19. The two decrements get overwritten by the assignment.

I'd expect 18 if the expression were a= --a + --a.

Have you tried compiling the C version with different optimization flags?

developmentalinsanity
I'd expect **17** for `--a + --a`, as that should be 9 + 8.
Andrzej Doyle
`--a + --a` in C could easily be `16`. It's up to the compiler.
Dave Hinton
A: 

Hello in fact it's normal:

a = 10 + 9

you can try with a = a-- + a-- + a--

it returns 27 ( 10 + 9 + 8)...

pgras
A: 

a= a-- + a--;

This invokes undefined behaviour in C/C++. You should not expect consistent results from this statement.

Michael Foukarakis
+2  A: 

In the expression

a = a-- + a--;

you have a lot of sub-expressions that need to be evaluated before the whole of the expression is evaluated.

a = a-- + a--;
          ^^^ <= sub-expression 2
    ^^^       <= sub-expression 1

What's the value of sub-expression 1? It's the current value of the object a.
What's the value of the object a?

If the sub-expression 2 was already evaluated, value of object a is 9, otherwise it is 10.

Same thing for sub-expression 2. Its value can be either 9 or 10, depending on whether sub-expression 1 was already evaluated.

The C compiler (don't know about Java) is free to evaluate the sub-expressions in any order

So let's say the compiler chose to leave the --s for last

a = 10 + 10;
a--; /* 19 */
a--; /* 18 */

but on the next compilation the compiler did the --s up front

/* value of sub-expression 1 is 10 */
/* value of sub-expression 2 is 9 */
a = 10 + 9; /* a = 9 + 10; */

or it could even save one of the a-- and use that for the final value of a

/* sub-expression 1 yields 10 and sets the value of `a` to 9 */
/* so yield that 10, but save the value for the end */
a = 10 + ???;
a = 18???; a = 19???;
/* remember the saved value */
a = 9

Or, as you invoked undefined behaviour, it could simply replace your statement with any of the following

  • a = 42;
  • /* */
  • fprintf(stderr, "BANG!");
  • system("format C:");
  • for (p=0; p<MEMORY_SIZE; p++) *p = 0;
  • etc ...
pmg