I wish that, if someone is overcome by the vapors of the NIH disease, such a person would confine their reinvention of the wheel to their personal time and not introduce such silliness to the workplace.
Of course, I wish for lots of things.
Now, this makes perfect sense if you understand the concept of sequence points, but you wouldnt see that explanation in most books.
To me, it seems like that would be evaluated by operator precedence...
++ has a higher precedence than +
So let i=1. The expression then becomes:
j = i++ + ++i;
j = {1}++ + ++{1};
j = 1 + 2; OR, j = 1 + 3;
Aha. And that's the undefined behavior.Ew. That seems like the type of problem which shouldn't have to be debugged, because the code shouldn't have been written like that to begin with.
Heck, it seems like the compiler shouldn't even allow that code to compile in the first place... But I guess there are technical problems with disallowing that? (Not the least of which is, it would break existing code.)
And if you want to get even funkier, try this in other languages (python yields 2, bash yields 4)
$ python -V
Python 2.6.1
$ python -c 'x=1;y=x++ + ++x; print y'
2
$ x=1; echo $((x++ + ++x))
4 y = x + (+(+(+(+x))))Concerning python's lack of pre and post increment, the decision was made primarily because there are a lot of confusing situations, such as the aforementioned, with the increment and decrement operators. However, the decision to allow x++x to be valid, and parsed as x + (+ x) = x + x, is itself terribly confusing and germane to the original discussion