Boxing

[SK]

What is the real use of boxing and unboxing
in what situations will it be used.
Since all types are utlmately dereived from object..what
is the need for boxing and unboxing.....help

 

[Jon Skeet [C# MVP]]

What is the real use of boxing and unboxing
in what situations will it be used.
Since all types are utlmately dereived from object..what
is the need for boxing and unboxing.....help

Boxing and unboxing makes it much easier to deal with value types in
situations where what is expected is a reference type. For instance, it
is boxing which allows us to add an int to an ArrayList, or set the
value in a DataRow to a float, etc.

 

[Niki Estner]

What is the real use of boxing and unboxing
in what situations will it be used.
Since all types are utlmately dereived from object..what
is the need for boxing and unboxing.....help

Of course all value types are derived from object, that's what makes boxing
possible from a language perspective. But (without boxing) value types
always live on the stack and reference types always live on the heap: If you
want to get a value type on the heap, you need a "reference type box" around
it, that's why it's called boxing.

Niki

 

[Jon Skeet [C# MVP]]

Of course all value types are derived from object, that's what makes
boxing possible from a language perspective.

There's actually some extra complexity there. The value type itself
*doesn't* derive from System.Object. The boxed value type derived from
System.Object (via System.ValueType). The two types have the same name.
It's all a bit odd - see section 8.2.4 of the CIL spec for more
information.

However, it's up to the language itself to define the boxing
conversions it wants to implement.

But (without boxing) value types
always live on the stack and reference types always live on the heap

Not true. For instance:

public class Test
{
int i = 5;

static void Main()
{
Test t = new Test();
}
}

That has created a value type within the Test type. The object itself
(containing the value type value) is on the heap.

See http://www.pobox.com/~skeet/csharp/memory.html

 

[Niki Estner]

There's actually some extra complexity there. The value type itself
*doesn't* derive from System.Object. The boxed value type derived from
System.Object (via System.ValueType). The two types have the same name.
It's all a bit odd - see section 8.2.4 of the CIL spec for more
information.

I should have mentioned that I was talking about *high-level* language
perspective, like C# or VB.net.

Not true. For instance:

public class Test
{
int i = 5;

static void Main()
{
Test t = new Test();
}
}

That has created a value type within the Test type. The object itself
(containing the value type value) is on the heap.

I assume you know what I meant.

Niki

 

[Jon Skeet [C# MVP]]

I assume you know what I meant.

Yup, but others don't necessarily. The reason I wrote the memory page
in the first place is that people say "Value types are always stored on
the stack" and then people reading that get (understandably, IMO)
confused as to where value type members of reference types actually
*do* live.

 

[Sijin Joseph]

Yes all types are derived from Object, but types that derive from
System.ValueType (aka value type) objects have different memory
semantics. Normal(reference) types in .Net are allocated memory on the
managed heap, whereas value types are allocated menory on the stack.
That is why there needs to be boxing, when a reference type object is
expected and we pass a value type, the runtime automatically allocates
memory on the heap and copies the value of the value type into the new
object.

Sijin Joseph
http://www.indiangeek.net
http://weblogs.asp.net/sjoseph

 

[Jon Skeet [C# MVP]]

Yes all types are derived from Object, but types that derive from
System.ValueType (aka value type) objects have different memory
semantics. Normal(reference) types in .Net are allocated memory on the
managed heap, whereas value types are allocated menory on the stack.

That's an oversimplification which isn't really true.

See http://www.pobox.com/~skeet/csharp/memory.html

 

[Sijin Joseph]

That's a great article Jon! I sure did miss the part where Value types
are fields of Reference types. But one question comes to mind, in this
case will boxing occur? (since the value is already on the heap)


Sijin Joseph
http://www.indiangeek.net
http://weblogs.asp.net/sjoseph

 

[Jon Skeet [C# MVP]]

That's a great article Jon! I sure did miss the part where Value types
are fields of Reference types. But one question comes to mind, in this
case will boxing occur? (since the value is already on the heap)

No. Boxing occurs when you need to view a value type as a reference
type - it's sort of when a value type value needs to be on the heap "on
its own" rather than as part of another object.

 

[Sijin Joseph]

Hi Jon,

Although i am sure that internally no boxing takes place in this case,
but surprisingly the compiler does generate the box instruction.

I compiles this code

class Class1
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
Test t = new Test();
ArrayList al = new ArrayList();
al.Add(t.a);
}
}

public class Test
{
public int a = 5;
}

and i got this IL

..method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() =
( 01 00 00 00 )
// Code size 31 (0x1f)
.maxstack 2
.locals init ([0] class ConsoleApplication1.Test t,
[1] class [mscorlib]System.Collections.ArrayList al)
IL_0000: newobj instance void ConsoleApplication1.Test::.ctor()
IL_0005: stloc.0
IL_0006: newobj instance void
[mscorlib]System.Collections.ArrayList::.ctor()
IL_000b: stloc.1
IL_000c: ldloc.1
IL_000d: ldloc.0
IL_000e: ldfld int32 ConsoleApplication1.Test::a
IL_0013: box [mscorlib]System.Int32 // Box call is generated
IL_0018: callvirt instance int32
[mscorlib]System.Collections.ArrayList::Add(object)
IL_001d: pop
IL_001e: ret
} // end of method Class1::Main



Sijin Joseph
http://www.indiangeek.net
http://weblogs.asp.net/sjoseph

 

[Jon Skeet [C# MVP]]

Although i am sure that internally no boxing takes place in this case,
but surprisingly the compiler does generate the box instruction.

I compiles this code

class Class1
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
Test t = new Test();
ArrayList al = new ArrayList();
al.Add(t.a);
}
}

public class Test
{
public int a = 5;
}

There's nothing surprising about a box happening here - adding an int
to an ArrayList will always box, as it's got to store it in an object
for the ArrayList to work. (Note that ArrayList.Add takes object, not
int.)

You'll see the same thing if you just try

al.Add(5);

 

[Sijin Joseph]

Well it's surprising because 't.a' is already on the heap, since it is
part of a reference type. What would be intresting is to see if the
boxing is actually taking place, although the box instruction is being
generated, is the JITer is actually creating a new object on the heap to
store the value. It would be intresting to look at the rotor sources to
check the same.

Sijin Joseph
http://www.indiangeek.net
http://weblogs.asp.net/sjoseph

Although i am sure that internally no boxing takes place in this case,
but surprisingly the compiler does generate the box instruction.

I compiles this code

class Class1
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
Test t = new Test();
ArrayList al = new ArrayList();
al.Add(t.a);
}
}

public class Test
{
public int a = 5;
}

There's nothing surprising about a box happening here - adding an int
to an ArrayList will always box, as it's got to store it in an object
for the ArrayList to work. (Note that ArrayList.Add takes object, not
int.)

You'll see the same thing if you just try

al.Add(5);

 

[Jon Skeet [C# MVP]]

Well it's surprising because 't.a' is already on the heap, since it is
part of a reference type.

Yes, but it's not a separate object. Note that al.Add isn't taking
"t.a" as the parameter - it's taking the *value* of t.a as the
parameter.

What would be intresting is to see if the
boxing is actually taking place, although the box instruction is being
generated, is the JITer is actually creating a new object on the heap to
store the value. It would be intresting to look at the rotor sources to
check the same.

The CLR *must* create a new object on the heap. Your instance of Test
is eligible for garbage collection, which means there must be another
copy of the data somewhere, and it must be on the heap.