Re boxed primitives in Java and .NET

One of my colleagues posted the following question once “why <i = i++> expression returns different results in C++ and Java/.NET?”. For instance, try this:

C/C++

int i = 1;
i = i++; 
printf("%d\n", i);

result is 2

Java

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

result is 1

Many C++ developers will argue that <i = i++> is left undefined in C++ (i.e. it is up to compiler implementers to return whatever they think it is most appropriate). However, at a more practical level, <i = i++> against a primitive int type, in C/C++, is a simple (optimized ASM code, avoiding all the formalities with moving to/from registers):

mov i, i
inc i

at the same "address location" (in a simplistic way). So the result is 2.

Now, let's look at what C++ suggests about operator++(int). It suggests making a copy of the current instance, increasing current instance and returning the copy. Following this rule, the result is:

class MyInt {
private:
	int i;
public:
	MyInt(int iVal) { i = iVal; };
	int val() const { return i; };
	MyInt(const MyInt& t) { i = t.val(); };

	MyInt& operator=(const MyInt& t) {
		i = t.val();
		return *this;
	};

	MyInt operator++(int) {
		MyInt t = *this;
		i++;
		return t;
	};
};

MyInt func() {
	MyInt i = MyInt(1);
	i = i++;
	return i;
}

int _tmain(int argc, _TCHAR* argv[])
{
	int i = 1;
	i = i++;
	_tprintf(_T("%d\n"), i);

	MyInt t = func();
	_tprintf(_T("%d\n"), t.val());
	return 0;
}

Result is
2
1

But it is exactly what Java/.NET returns. From this, it is logical to conclude that Java/.NET primitives are boxed (which seems to be logical, otherwise it is hard to imagine how to support platform independence in Java/.NET, for example replacing the above class with a structure like "struct MyInt { int i : 32; };" in order to support 32 bits integers). Also this means that C/C++ works faster with primitives :)