1

I am a little bit confused, if I create an instance of a class Test it means that into the stack creates the reference into a heap where store field a.

class Test
{
    public int a;
}

Test test = new Test();
test.a = 10;

Here I create o, so it means that into the stack creates the reference into a heap where store value 10. As far as I understand in both situations we have the same binary representation of variables into a heap.

object o = 10;

Why in the second case I get boxing but in the first one no boxing?

Rand Random
  • 7,300
  • 10
  • 40
  • 88
Yura Pazyn
  • 11
  • 3
  • 3
    Well `a` is of type `int` and you are setting an `int` to it, so `int` to `int`, so why would boxing be required? while on the other code you are setting `int` to `object`, so two different types. – Rand Random Jan 13 '22 at 11:47
  • 2
    Boxing means taking a value type, that lives inside a variable wherever that variable is stored, and instead storing it on the heap. It is the act of allocating memory on the heap for a value type and copying the value there. In the first example you are sort of doing the same thing, you're allocating space for an object that contains an int field. But storing a value into that field does not require boxing because the int variable is already located on the heap. Thus, you don't need to allocate separate memory for the int in that object. – Lasse V. Karlsen Jan 13 '22 at 11:50
  • What you have in the heap will be different because the class will include additional information while the boxed `int` will just be the value of the `int`. – juharr Jan 13 '22 at 11:58
  • @juharr Not so sure about that. The box is essentially the same thing as `Test`: a type handle + fields – Charlieface Jan 13 '22 at 12:00
  • Or maybe you want to provide a more interesting example by making `a` an object in the test class – usr-local-ΕΨΗΕΛΩΝ Jan 13 '22 at 12:01

1 Answers1

0

In the second case, you are instantiating a heap variable (32, 64 bits long) that points to another area in the heap where the actual 32-bit 10 is stored.

In the first case, the heap area containing the object stores the full value of the integer value

usr-local-ΕΨΗΕΛΩΝ
  • 26,101
  • 30
  • 154
  • 305
  • That's the same things though: `test` contains a *reference* to an object of `Test`, and `o` contains a *reference* to an object of `int`. And the stack/heap is an [implementation details](https://ericlippert.com/2009/04/27/the-stack-is-an-implementation-detail-part-one/). What OP wants to know is why `o` is boxed, and `test` is not, and that is to do with the value type/reference type semantic: value types must be boxed in order to get a reference to it, reference types do not – Charlieface Jan 13 '22 at 12:01
  • @Charlieface Could you help me, if I execute test.a=10, it means that compiler search heap allocation by the test reference and in the heap change 4 bytes of integer field a, but in the second one (object o) is also reference to heap where store 4 bytes integer. So if it makes the same operations to change or get value, is it mean that boxing unboxing is performance equal to change, get value of class field? Or boxing is slowly because of low level realization details? – Yura Pazyn Jan 13 '22 at 22:00
  • @YuraPazyn You're not making a huge amount of sense (perhaps mistranslation?) but basically, if you set an `int` field of an object to `10` you are not creating a new object, whereas if you set `o` to `10` then you get a new object. This causes an extra allocation due to boxing, so yes it is slower if you use it continually. The heap itself is not relevant: it's the fact that `test` is a reference to an object, and `test.a = 10` changes a field on that object, whereas `o = 10` replaces the whole reference with a new boxed `int` – Charlieface Jan 13 '22 at 22:06
  • @Charlieface Great, now I understand! What about unboxing, is it the same performance as get field value? – Yura Pazyn Jan 13 '22 at 22:25