Question on boxing

[Jay]

I've been reading that boxing converts a value type to a reference type. If I understand this
correctly, the type on the heap is copied onto the stack.

This sound inefficient to me. Why doesn't C# just create a reference variable that points to the
object on the heap, which would act in a similar way to a true reference type?

[Bruce Wood]

Re: Question on boxing

On Aug 8, 9:07 am, "Jay" <nospamwrote:

I've been reading that boxing converts a value type to a reference type. If I understand this
correctly, the type on the heap is copied onto the stack.
>
This sound inefficient to me. Why doesn't C# just create a reference variable that points to the
object on the heap, which would act in a similar way to a true reference type?

It's the other way around: the value on the stack (or inlined in
another object on the heap) is copied into a new object on the heap.

However, your question is still valid: why copy a value when you can
hold a pointer? The answer is that you can take the performance hit up
front, copying the value, or you can take it every time you use the
boxed value. That is, you can take a performance hit copying a value
(which, according to MS recommendations , should be small, no longer
than 16 bytes, so that it can be copied quickly), or you can take a
performance hit following a pointer over and over again.

I'd rather take the performance hit up front, personally, particularly
considering that it's nothing more than copying a few bytes from one
place to another.

[Jon Skeet [C# MVP]]

Re: Question on boxing

Bruce Wood <brucewood@cana da.comwrote:

On Aug 8, 9:07 am, "Jay" <nospamwrote:

I've been reading that boxing converts a value type to a
reference type. If I understand this
correctly, the type on the heap is copied onto the stack.

This sound inefficient to me. Why doesn't C# just create a
reference variable that points to the
object on the heap, which would act in a similar way to a
true reference type?

>
It's the other way around: the value on the stack (or inlined in
another object on the heap) is copied into a new object on the heap.
>
However, your question is still valid: why copy a value when you can
hold a pointer? The answer is that you can take the performance hit up
front, copying the value, or you can take it every time you use the
boxed value. That is, you can take a performance hit copying a value
(which, according to MS recommendations , should be small, no longer
than 16 bytes, so that it can be copied quickly), or you can take a
performance hit following a pointer over and over again.
>
I'd rather take the performance hit up front, personally, particularly
considering that it's nothing more than copying a few bytes from one
place to another.

There's more to it than that.

Consider the case where you do:

object Return5()
{
int x = 5;
return x;
}

If it just returned a pointer to the original stack value then:

a) How would it know what type the value was meant to be?
b) What happens after the stack is popped at return time?

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

[Peter Duniho]

Re: Question on boxing

Jon Skeet [C# MVP] wrote:

There's more to it than that.
>
Consider the case where you do:
>
object Return5()
{
int x = 5;
return x;
}
>
If it just returned a pointer to the original stack value then:
>
a) How would it know what type the value was meant to be?

Well, it'd have to store that information somewhere, of course. Maybe
you'd just change the language so that all stack frames include type
information for all variables in the frame, and the pointer wouldn't be
just to the variable data, but to that typed information describing the
variable data.

Alternatively, you could wrap the reference for the stack variable in
some sort of container. We could call it, oh...I don't know...a
"package"? No, too long. How about "carton". No, reminds me of
cigarettes. Maybe the word "box" would work?

:)

b) What happens after the stack is popped at return time?

Oh, I know! You just capture the variable, the way anonymous delegates
work. :)

My biggest issue with the idea of referencing the original variable is
that it means that the value could change externally to the boxed value,
and that change would be reflected in the user of the boxed type. This
is contrary to the normal behavior of value types. IMHO, one main point
of boxing is to wrap the value in something that can be used as a
reference type, but which retains the normal behavior of a value type.
If you just refer to the original value, which is available for changing
by other code elsewhere, then the boxed value type doesn't work like a
value type any more.

Pete

[Ignacio Machin \( .NET/ C# MVP \)]

Re: Question on boxing

Hi,

"Jay" <nospamwrote in message
news:%2383wFZd2 HHA.4400@TK2MSF TNGP06.phx.gbl. ..

I've been reading that boxing converts a value type to a reference type.
If I understand this
correctly, the type on the heap is copied onto the stack.

It's the opposite, it's copied from the stack to the heap, but is not
precisely that, the value is copied but then you get a reference to it
through an instance of Object class.

This sound inefficient to me. Why doesn't C# just create a reference
variable that points to the
object on the heap, which would act in a similar way to a true reference
type?
>

It's a problem of how long the variable will "live" , if you only keep it in
the stack, as soon as that stack frame is released the variable is lost.
Wether in the heap it can live for as long as it's referenced.

[Jay]

Re: Question on boxing

Thanks for your replies everyone. I'm still lacking enough knowledge to fully understand the
reasons, but it's now clear to me that it's not as simple as I first thought!

Jay

"Jay" <nospamwrote in message news:%2383wFZd2 HHA.4400@TK2MSF TNGP06.phx.gbl. ..
I've been reading that boxing converts a value type to a reference type. If I understand this
correctly, the type on the heap is copied onto the stack.

This sound inefficient to me. Why doesn't C# just create a reference variable that points to the
object on the heap, which would act in a similar way to a true reference type?