As others have noted, the behaviour of this code is undefined in C/C++. You can get any result whatsoever.
The behaviour of your C# code is strictly defined by the C# standard.
Surely there must be some rationale for both languages to implement it differently?
Well, suppose you were designing C#, and wished to make the language easy for C++ programmers to learn. Would you choose to copy C++'s approach to this problem, namely, leave it undefined? Do you really want to make it easy for perfectly intelligent developers to accidentally write code that the compiler can just make up any meaning for that it wants?
The designers of C# do not believe that undefined behaviour of simple expressions is a good thing, and therefore we have strictly defined what expressions like this mean. We cannot possibly agree with what every C++ compiler does because different C++ compilers give you different results for this sort of code, and so we cannot agree with all of them.
As for why the designers of C++ believe that it is better to leave simple expressions like this to have undefined behaviour, well, you'll have to ask one of them. I could certainly make some conjectures, but those would just be educated guesses.
I've written a number of blog articles about this sort of issue; my most recent one was about almost exactly the code you mention here. Some articles you might want to read:
How the design of C# encourages elimination of subtle bugs:
http://blogs.msdn.com/ericlippert/archive/2007/08/14/c-and-the-pit-of-despair.aspx
Exactly what is the relationship between precedence, associativity, and order of execution in C#?
http://blogs.msdn.com/ericlippert/archive/2008/05/23/precedence-vs-associativity-vs-order.aspx
In what order do the side effects of indexing, assignment and increment happen?
http://blogs.msdn.com/ericlippert/archive/2009/08/10/precedence-vs-order-redux.aspx