You're Doing it Wrong

Relearning boxing

Was reading a post over here and (re)learned something about boxing value types in .NET. Go there, read, come back and continue reading.

What struck me as odd while I was reading was what occurrs between steps 6 and 7 in the last diagram. Intuitavely, it would seem that changing the value of a boxed value type wouldn't create a new object. I had to go back to CLR Via C# (an excellent book that every .NET developer should own) to make sure Lee was correct. And he is.

Essentially, when you box a value type you are creating an immutable object, similar to a string. Now, its important to note that this is C# we're talking about; C++ .NET (and possibly other implementations of .NET languages) allow you to change the value within a boxed value type. To see this behavior in action, try this simple console application:

static void Main(string[] args)

{

int i = 5;

object o = i;

object p = o;

o = 25;

Console.Write(string.Format("Object o: {0}; object p:{1}",o,p));

Console.Read();

}

What do you expect to be printed? In fact, this program prints out "Object o: 25; object p: 5". This is because the last line, o=25, creates a new boxed integer rather than changing the value of the current boxed integer referenced by o.

The immutability of boxed value types is definitely something you need to keep in mind.

Programming Post by: McGurk at 02:35 PM | 4 Replies | Reply
Kick this post:

But hey, assigning anything into any variable won't change its value (unless it passed as out/ref parameter).
MyClass m=new MyClass("a","b");
MyClass m2=m;
m2=new MyClass("c","d");

m is still a/b, m2 is c/d.

1 Posted by nm on April 23, 2007 07:04 PM (x1PS5)

Well, we're talking about different things. You're dealing exclusively with objects (variables on the stack holding int pointers to data kept on the heap), whereas I'm mixing them with primitives (variables on the stack holding a value).

In C# you can't have two value type variables pointing to the same location on the stack (at least not witout passing by ref that variable to a function!).

You can have two reference variables pointing to the same object on the heap. So it is easy to conceptualize that, after altering the state of the object on the heap via its one of the variables, both variables will show the state as changed. It is only expected because they point to the same object.

If that object on the heap is a boxed primitive, however, this does not hold true. That's the gotcha moment I'm trying to point out in this post.

2 Posted by McGurk on April 23, 2007 09:11 PM (Ri74D)

Nice follow-on post, thanks McGurk. BTW, where is your RSS feed?

3 Posted by Lee Richardson on April 24, 2007 01:44 PM (YYHE4)

youredoingitwrong.mee.nu/atom.xml and /feed.xml. Got problems with them right now; the blarg software is in beta...

4 Posted by McGurk on April 24, 2007 05:46 PM (Ri74D)

Hide Comments | Add Comment

Press butan, recieve imagelet. Hover for preview. Imagelets are pasted at the end of your comment. Think ahead.