1

Possible Duplicate:
Could anyone explain these undefined behaviors (i = i++ + ++i , i = i++, etc…)
Is there any difference between the Java and C++ operators?

Why unary operators give different result in c++ and java?

Check this out:

int i = 1;
i = i++ + ++i;
print i  (with cout or println)

In java: prints 4

In c++: prints 5

Why ?

Community
  • 1
  • 1
joao
  • 97
  • 1
  • 10
  • 5
    This prints `4` for me in Java. – Keppil Jul 03 '12 at 12:44
  • 3
    This is `undefined behaviour`. There are many, many posts. A quick search suggests http://stackoverflow.com/questions/4176328/undefined-behavior-and-sequence-points and http://stackoverflow.com/questions/4638364/undefined-behavior-and-sequence-points-reloaded to start with. Also note I get `5` with g++. – BoBTFish Jul 03 '12 at 12:44
  • @Keppil Thanks, but actually, I'm not sure whether the cited comment was correct, so deleted mine. – Daniel Fischer Jul 03 '12 at 12:49
  • Yap! Sorry @Keppil . The prints were changed. Sorry :-P – joao Jul 03 '12 at 13:00

6 Answers6

9

In C++ the behavior of a statement such as i = i++ + ++i; is actually undefined so the fact that the behavior differs is not so surprising.

In fact it shouldn't be surprising if two different C++-compilers produce different behavior for the C++ statement i = i++ + ++i;.

Related question:

Community
  • 1
  • 1
aioobe
  • 413,195
  • 112
  • 811
  • 826
  • 5
    Java _actually_ specifies the value of this expression, where C++ leaves it up to the compiler. – Louis Wasserman Jul 03 '12 at 12:43
  • C++ actually leaves it up to the hardware. Java doesn't have that problem, it only runs on the JVM. – Bo Persson Jul 03 '12 at 12:53
  • 1
    @BoPersson: I don't think it is about the hardware, though. – nhahtdh Jul 03 '12 at 13:06
  • @nhahtdh - But I do. I have seen references to systems where the memory bus would lock on a simultaneous read and write to the same address. That's why it is undefined, and not just unspecified. – Bo Persson Jul 03 '12 at 13:12
  • In *some* cases I'm sure the compiler leaves it to the hardware. Whether or not this was the *reason* the language creators chose to make it undefined no one except themselves know. – aioobe Jul 03 '12 at 13:16
  • @BoPersson: I cannot see the link between them, but I will take it at face value for now and see if I come across anything that is relevant. – nhahtdh Jul 03 '12 at 13:20
1

it better explained with this code:

int i = 1;
int j =0;
j = i++ + ++i;
print j  (with cout or println)

In java the i++ and ++i have the same result i is incremented by 1 so you do: 2 + 3 = 5 i will be 5 afterwards. j will be 5 afterwards

in c++ i++ and ++i behave differently i++ increments in place while ++i increments afterwards.

so it reads 2+ 2. j will be 4 and i will be 5.

C. Holzberger
  • 318
  • 2
  • 4
1

C++ and Java are different languages so there is different effect. See operators priority.

In Java ++ (postfix and prefix) are on same line, while in C++ they are with different priority.

alaster
  • 3,821
  • 3
  • 24
  • 32
1

In Java, the post fix increment ++ operator is somewhat "atomic" (not threading related sense) in the sense that the value is evaluated into the expression and the increment happens without the interference of other operators.

Operator precedence table of Java from Wikipedia.

i = i++ + ++i
i = ((i++) + (++i))
i = (1 + (++i)) // i = 2
i = (1 + 3) // i = 3
i = 4

For C, the behavior is undefined by standard.

Operator precedence of C from Wikipedia.

nhahtdh
  • 55,989
  • 15
  • 126
  • 162
0
i = i++ + ++i;

results in unspecified behaviour, which means you can get different results with different compilers or different compiler settings.

SingerOfTheFall
  • 29,228
  • 8
  • 68
  • 105
  • 1
    I believe it is undefined rather than unspecified. Unspecified means the compiler must choose something and do it consistently. Undefined means you're on your own... – BoBTFish Jul 03 '12 at 12:49
  • 1
    @BoBTFish, nope, the Standart says "1.3.13 unspecified behavior [defns.unspecified] behavior, for a well-formed program construct and correct data, that depends on the implementation. The implementation is not required to document which behavior occurs.". Undefined behavior, on the other hand, is "1.3.12 undefined behavior [defns.undefined] behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which this International Standard imposes no requirements.". The line i = i++ + ++i; is a correct program, so it's unspecified behavior. – SingerOfTheFall Jul 03 '12 at 12:58
  • I don't have a quote from the standard, but a quote from Bjarne is a good start: `Basically, in C and C++, if you read a variable twice in an expression where you also write it, the result is undefined.` http://www2.research.att.com/~bs/bs_faq2.html#evaluation-order – BoBTFish Jul 03 '12 at 13:27
  • @BoBTFish, I think we have a little ambiguosity in terminology here. I strongly believe that a phrase "if you read a variable twice in an expression where you also write it, the result is undefined" means that the result is undefined for the **developer**. The quote from the standart that I've posted, is mentioning compilers, meaning that unspecified behavior is unspecified _by the Standart_ for the _compilers_. So i think we are just talking about the same thing from different points of view here. – SingerOfTheFall Jul 03 '12 at 13:37
  • The Standart, for example, clearly references the line `i = v[i++];`, which is almost the same as what Bjarne has, and says "the behavior is unspecified". Also note how Bjarne [says](http://www2.research.att.com/~bs/bs_faq2.html#undefined): "Note that the meaning of those terms differ from their definition of the ISO C standard and from some common usage. You can get wonderfully confused discussions when people don't realize that not everybody share definitions. " – SingerOfTheFall Jul 03 '12 at 13:41
  • I do know what you mean, I was just under the impression that the `int + int` did not create a sequence point (which would guarantee the side effects on one side have all completed before evaluating the other side), and the order of evaluation for `i++` and `++i` was *unspecified*, overall resulting in behaviour that was *undefined*. However, I may be wrong, and since the language in the standard has changed for c++11 (no more sequence points), I can't find what I want to back myself up. – BoBTFish Jul 03 '12 at 13:44
  • @BoBTFish, Well, then let's agree that we were both thinking about the same ;) – SingerOfTheFall Jul 03 '12 at 13:45
  • 1
    I think I've found what I want. This is the C++11 final draft (N3092), so section numbering may have changed. Section `1.9.15`: `Except where noted, evaluations of operands of individual operators and of subexpressions of individual expressions are unsequenced... If a side effect on a scalar object is unsequenced relative to either another side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined... i = v[i++]; // the behavior is undefined` – BoBTFish Jul 03 '12 at 14:03
  • @BoBTFish, Ok, you have convinced me! I've also just noticed that I've been reading the previous version of the standart which is ISO/IEC 14882:2003. My apologies. – SingerOfTheFall Jul 03 '12 at 14:07
0
int i = 1;
i = i++ + ++i;
System.out.println(i);

int i = 1;
int j = i++ + ++i;
System.out.println(j);

give always 4 because in Java parse expression from left to right (LALR).

cl-r
  • 1,264
  • 1
  • 12
  • 26