2

Possible Duplicate:
What is boxing and unboxing and what are the trade offs?

Hi, From my understanding: When I assign data of value type to (reference) type object variable, it gets boxed and the result is not actual reference as it points to copy of the value stored on the heap. Is that right? Thanks

Community
  • 1
  • 1
Lojolnik
  • 31
  • 2

3 Answers3

6

Well, not quite. (I misread your post to start with.)

The result is a real reference - but it doesn't refer to your original variable. It refers to an object on the heap which contains a copy of the value your variable held when boxing occurred. In particular, changing the value of your variable doesn't change the value in the box:

int i = 10;
object o = i;
i = 11;
Console.WriteLine(o); // Prints 10, not 11

C# doesn't let you have direct access to the value inside the box - you can only get it by unboxing and taking a copy. C++/CLI, on the other hand, allows the value inside the box to be accessed separately, and even changed. (You can still potentially change the value in a box with C# - for example if the value type implements some interface and the interface methods mutate the value.)

Often the reference type which causes boxing is "object" but it could be some interface the value type implements, or just System.ValueType.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
1

This might help you

int i = 1;
object o = i;   // boxing on the heap
int j = (int) o;    // unboxing to the stack
Bjorn Bailleul
  • 3,055
  • 1
  • 20
  • 25
0

Yes for the first part, assigning a value type to a reference variable will use boxing. Basically using a value type in any context where a reference type is required will box the value.

And yes, (in the current implementation) the boxing operation will copy the value type to the heap, and return a reference to that location, even if the value is already on the heap (e.g. a value type property of an object), so you won't get a reference to the original value variable, but that is an implementation detail anyway, as value types should be treated as immutable.

SWeko
  • 30,434
  • 10
  • 71
  • 106
  • @SWeko: The fact that boxing makes a copy is *not* an implementation detail. The heap is an implementation detail, but the independence of the box from the original variable isn't. The code in my answer is guaranteed to print 10 not 11, for example. – Jon Skeet Jan 19 '11 at 07:59
  • @JonSkeet: I think the immutability is the concept, and the copy is the implementation detail. The code will still print 10 if the boxing is not copied, and the i=11 just gets a new 11 for i, without mutating the original. – SWeko Jan 19 '11 at 08:04
  • @SWeko: But if it wasn't making a copy - if the reference was actually referring to the *variable* - then changing the value of the variable would change the value shown when dereferencing, wouldn't it? Do you want me to find the bit of the C# spec which guarantees the copy? Note that just because value types usually *should* be immutable also doesn't mean that they are... but the copy is guaranteed anyway. – Jon Skeet Jan 19 '11 at 08:10
  • @SWeko: From section 4.3.1 of the C# 4 spec: "A boxing conversion implies *making a copy* of the value being boxed." (The italics are even in the spec.) – Jon Skeet Jan 19 '11 at 08:18
  • @JonSkeet: If int was immutable, it would not be possible to change the value, so a reference to the original would not be a problem. Copying makes it appear immutable, and that is fine in my book. The language spec does define that a copying will take place (section 4.3.1) but what i'm trying to say is that, if we **treat** the value type as immutable, whether there is or isn't copying is unimportant. – SWeko Jan 19 '11 at 08:20
  • @SWeko: `int` *is* immutable. There are no methods on it which change the value. However, you can change the value of a variable to be a different value - a different set of bits. That doesn't change the immutability of `int` itself. There is no way of changing the value of an `int` variable without using the assignment operator. I fail to see how you can claim that copying is an implementation detail when it's *specified behaviour*. Any implementation *not* making a copy would simply not be conforming to the spec... which means it's *not* an implementation detail. – Jon Skeet Jan 19 '11 at 08:26
  • @JonSkeet: Sorry, I misspoke :) By definition, anything specified in the spec is *not* an implementation detail. However, the immutability is the goal we achieve by implementing copying. If it was implemented in any other way, the goal would still be met. – SWeko Jan 19 '11 at 08:37
  • @SWeko: I still think you're confusing whether or not a *type* is immutable with whether or not a value of that type is stored in a read-only variable. A value type can be as immutable as you like, but if I'm storing the value in a non-read-only variable, you *have* to take a copy. – Jon Skeet Jan 19 '11 at 09:51