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.....he lp

[Jon Skeet [C# MVP]]

SK <an*******@disc ussions.microso ft.com> wrote:

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.....he lp

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Niki Estner]

"SK" <an*******@disc ussions.microso ft.com> wrote in
news:9d******** *************** *****@phx.gbl.. .

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.....he lp

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]]

Niki Estner <ni*********@cu be.net> wrote:

"SK" <an*******@disc ussions.microso ft.com> wrote in
news:9d******** *************** *****@phx.gbl.. .

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.....he lp
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.ValueTyp e). 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

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Niki Estner]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in
news:MP******** *************** @msnews.microso ft.com...

...
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.ValueTyp e). 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.

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.

:-)
I assume you know what I meant.

Niki

[Jon Skeet [C# MVP]]

Niki Estner <ni*********@cu be.net> wrote:

But (without boxing) value types
always live on the stack and reference types always live on the heap
Not true. For instance:

<snip>
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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Sijin Joseph]

Yes all types are derived from Object, but types that derive from
System.ValueTyp e (aka value type) objects have different memory
semantics. Normal(referenc e) 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

SK wrote:

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.....he lp

[Jon Skeet [C# MVP]]

Sijin Joseph <si************ ***@hotmail.com > wrote:

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

That's an oversimplificat ion which isn't really true.

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

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[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] wrote:

Sijin Joseph <si************ ***@hotmail.com > wrote:

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

That's an oversimplificat ion which isn't really true.

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

[Jon Skeet [C# MVP]]

Sijin Joseph <si************ ***@hotmail.com > wrote:

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too