Question on boxing

J

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?
 
B

Bruce Wood

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

Jon Skeet [C# MVP]

Bruce Wood said:
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?
 
I

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

Hi,

Jay said:
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.
 
P

Peter Duniho

Jon said:
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
 
J

Jay

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" <nospam> wrote in message 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?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Why boxing? 1
Boxing effect on struct methods 1
Question about Boxing 1
Question on boxing 2
reference back to original value 2
Boxing and Unboxing ?? 161
boxing reference type? 3
Value vs Reference Types 5

Top