Boxing & Unboxing F1 F1 F1...

[Justine]

Hi All,

I need a small clarification with regard to Boxing.

struct Currency
{ ......... }

Currency Bal = new Currency;
Object Obj = Bal;

i read that when implicit boxing is taking place, ther
will be an hidden class (Reference Type) of type Currency
created internal by .NET Framework (to which direct
access is not easy). And when actual boxing is taking
place the object of the hidden class gets instanciated
and reference is store in "Obj".
My Doubt:- Does this mean that there will be 2 copies of
the data on RAM (One for Value Type ie struct Currency
and other for Hidden Class. if yes then isn't it
overhead?). Kindly help me in understanding this.

Thanz in Advance...
Justine

 

[Jon Skeet [C# MVP]]

I need a small clarification with regard to Boxing.

struct Currency
{ ......... }

Currency Bal = new Currency;
Object Obj = Bal;

i read that when implicit boxing is taking place, ther
will be an hidden class (Reference Type) of type Currency
created internal by .NET Framework (to which direct
access is not easy). And when actual boxing is taking
place the object of the hidden class gets instanciated
and reference is store in "Obj".
Yup.

My Doubt:- Does this mean that there will be 2 copies of
the data on RAM (One for Value Type ie struct Currency
and other for Hidden Class. if yes then isn't it
overhead?). Kindly help me in understanding this.

Well, there'll be two copies while the value type variable is still in
scope, yes. The fact that the object can live on outside the scope of
the variable which initially refers to it means that there *has* to be
a separate copy, really. I'm not sure whether or not I'd call that
overhead, but certainly boxing/unboxing is something you should always
be aware of when thinking about your types.

 

[Justine]

Thanz Jon

Justine

-----Original Message-----


Well, there'll be two copies while the value type variable is still in
scope, yes. The fact that the object can live on outside the scope of
the variable which initially refers to it means that there *has* to be
a separate copy, really. I'm not sure whether or not I'd call that
overhead, but certainly boxing/unboxing is something you should always
be aware of when thinking about your types.

--
Jon Skeet - <[email protected]>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
.

 

[Mark Broadbent]

Hi Jon forgive my ignorance here (im a c# newbie), but I have a further
question...
When boxing a value type, a temporary reference is created to allow it
to be treated as a reference type for instance..

int I = 100;
object O;
O = I;

So that if my understanding is correct, line1 creates the integer I on
the stack, line two creates an object reference pointer on the stack
and line three causes the object O reference pointer to point
(indirectly) to the integer I.
Would I be right in thinking that since when you instanciate a new
object instance it creates the object on the heap, in this case does
somekind of object (which is presumably the object box) get created on
the heap which references the stack int I?

in simpler terms....

STACK HEAP
O(objref)---------->I(Obj box which points to)
|
|
I(Integer) <--------



Thanks in advance,

Br,

Mark.

--

Br,
Mark Broadbent
mcdba , mcse+i
=============

 

[Jon Skeet [C# MVP]]

Hi Jon forgive my ignorance here (im a c# newbie), but I have a further
question...
When boxing a value type, a temporary reference is created to allow it
to be treated as a reference type for instance..

int I = 100;
object O;
O = I;

So that if my understanding is correct, line1 creates the integer I on
the stack, line two creates an object reference pointer on the stack
and line three causes the object O reference pointer to point
(indirectly) to the integer I.

Line three causes the object O reference pointer to point to a *new*
object, which has the current value of I.

Would I be right in thinking that since when you instanciate a new
object instance it creates the object on the heap, in this case does
somekind of object (which is presumably the object box) get created on
the heap which references the stack int I?

It doesn't reference the stack at all - it's a copy, effectively. So if
you change the value of I afterwards, that wouldn't change the object O
refers to at all.

Hope that helps.

 

[Jason M]

Mark,

Just to add to Jon's reply...suppose you were to pass the
object reference you created in line 2 off to some other
asynchronous method that might not get to using it before
your initial function returns. If the reference were
pointing back to the stack someplace that value would now
be gone...

JM

 

[Mark Broadbent]

--

Br,
Mark Broadbent
mcdba , mcse+i
=============