Boxing

  • Thread starter Thread starter SK
  • Start date Start date
S

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
 
SK said:
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
Click to expand...

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.
 
SK said:
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
Click to expand...

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
 
Niki Estner said:
Of course all value types are derived from object, that's what makes
boxing possible from a language perspective.
Click to expand...

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
Click to expand...

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
 
Jon Skeet said:
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.
Click to expand...

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.
Click to expand...

:-)
I assume you know what I meant.

Niki
 
I assume you know what I meant.
Click to expand...

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.
 
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
 
Sijin Joseph said:
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.
Click to expand...

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

See http://www.pobox.com/~skeet/csharp/memory.html
 
Sijin Joseph said:
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)
Click to expand...

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.
 
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
 
Sijin Joseph said:
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;
}
Click to expand...

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);
 
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

Sijin Joseph said:
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;
}
Click to expand...


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);
Click to expand...
 
Sijin Joseph said:
Well it's surprising because 't.a' is already on the heap, since it is
part of a reference type.
Click to expand...

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.
Click to expand...

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.
 
Back
Top