views:

605

answers:

5
+8  Q: 

Boxing vs Unboxing

Hello,

Another recent C# interview question I had was if I knew what Boxing and Unboxing is. I explained that value types are on Stack and reference types on Heap. When a value is cast to a reference type, we call it boxing and vice versa.

Then he asked me to calculate this:

int i = 20;
object j = i;
j = 50;

What is i?

I messed it up and said 50, where its actually 20. Now I think understand it why, however when I was playing with different combinations I was surprised to see this:

Object a = 1; // Boxing
Object b = a; // referencing the pointer on stack to both objects on heap
a = 2; // Boxing

I was expecting to see b == 2 as well, but it isn't, why? is it because the second boxing destroys and replaces the whole (a)-object on heap?

Because if I do this, its fine:

public class TT
{
    public int x;
}

TT t = new TT();
t.x = 1;
TT t2 = new TT();
t2.x = 2;
t = t2;
t.x = 3;

What is t2.x ? It should be 3, and it is. but this is not an example of boxing/unboxing at all, is this correct? So how would you summarize this? Could the values ever become the same in a boxing/unboxing conversion as above ?

Thanks, kave

+2  A: 
  1. You're right the second assignment replaces the first. It doesn't change the boxed value.

  2. Your example doesn't make use of boxing. The value (int) is stored as an int and not boxed.

  3. No, boxing still keeps the immutability guarantee.

__grover
Hi, Thank you for your answer. may you please elaborate a bit more on "boxing still keeps the immutability guarantee."?Thankskave
Kave
Most value types are immutable, for example: An int can only have one value. If you change the value you're essentially creating a new int. .NET keeps this immutability for boxed objects: If you assign it a new value, you're creating a new boxed int. The same applies to boxed structures.
__grover
Makes perfectly sense. Thanks
Kave
+2  A: 

I was expecting to see b == 2 as well, but it isn't, why? is it because the second boxing destroys and replaces the whole (a)-object on heap?

No, not exactly. It leaves the object as it is on the heap (as the b variable is also referencing it) and creates a new object for the new value, which the a variable will reference.

You are right that your second example does not use boxing. You can't access a value that is boxed in any other way than unboxing it, so there is no way to change a boxed value.

Not even a mutable struct like Point can be changed when boxed. To access the properties of the struct you have to unbox it, so you can't change the boxed struct in place.

Guffa
+1  A: 

b is still 1 because b is a reference that still points to the object on the heap with a value of 1. a is 2 because you assigned it to a new object on the heap with a value of 2.

t2.x is 3 because t and t2 are two different references to the same object on the heap.

Aaron Daniels
A: 

Hi, I think the answer to your question with unboxing is that: The result of an unboxing conversion is a temporary variable (more details: link).

I think you were trying to do sth like:

object a = new Point(10,10);
object b = new Point(20,20);
a = b;

((Point) b).X = 30; //after this operation also a.X should be 30

The above code won't compile - details in the link above, and I think this is the answer to your question:

I was expecting to see b == 2 as well, but it isn't, why? is it because the second boxing destroys and replaces the whole (a)-object on heap?

empi
+2  A: 

Very short: boxing means creating a new instance of a reference type. If you know this, you understand that one instance does not change by creating another.

What you are doing with a = 2 is not changing the value in the 'box', you are creating a new instance of a reference type. So why should anything else change?

Stefan Steinegger
nice explanation, now what happens when you unbox? does the new instance of reference type get destroyed?
SoftwareGeek
Reference types are always destroyed by garbage collection. So it will be destroyed when not referenced anymore.
Stefan Steinegger