Hi,

Ok ! My understanding (certainly wrongful!) was that you require an object
header to dispatch method calls. which is not true for value type instances.

Thanks for answering my question with patience

Happy thakns giving, everyone

Regards,
Girish Jain

From: "Shawn A. Van Ness" <[EMAIL PROTECTED]>
Reply-To: "Unmoderated discussion of advanced .NET topics."
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Methods Calls on value types
Date: Thu, 25 Nov 2004 11:52:45 -0800

Because there's no reason to box it.  All that's needed to perform an
instance method call is a pointer to the object (as the first
parameter -- the 'this pointer' as we used to say in C++)...  the
'ldloca' instruction provides that, nicely enough, in the above
example..

And if you think about it, boxing isn't really a viable option at all.
 The process of boxing involves making a bitwise copy of the
valuetype, on the heap.  So if valuetypes had to be boxed before each
and every method-call...  they'd all be immutable!  The method calls
would be operating on boxed copies, not the originals.

Happy Thanksgiving, everyone...
-S

On Thu, 25 Nov 2004 19:30:32 +0530, Hotmail <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> Firstly - Sorry for a 2 day break!
> Secondly - Thanks a lot for such a beautiful explanation. It has
certainly
> increased my knowledge.
>
> Ooops!! After telling the entire story, I forgot the very basic thing -
to
> ask my specific question.
>
> My question was (It may sound dumb!) :
> Why the value type instance was not boxed in the supplied code ?
>
> Regards,
> Girish Jain
>
>
>
> ----- Original Message -----
> From: "Shawn A. Van Ness" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, November 24, 2004 1:46 AM
> Subject: Re: [ADVANCED-DOTNET] Methods Calls on value types
>
> > > IL_0002:  ldloca.s   V_0              // Load local variable address
on
> to the stack
> >
> > Sounds like you understand, just fine.  The CPU pushes the address of
> > the valuetype onto the stack, before making the function call.  That's
> > a pointer, on the stack, *to* something else on the stack (but
> > slightly higher up).
> >
> > I think the real question you're asking is "why is this verifiable?"
> > Ordinarily, you're not allowed to go passing around pointers to things
> > on the stack...  well, actually you are -- the above IL code
> > demonstrates that -- you're just not allowed to hold onto that pointer
> > beyond the life of what it points to.
> >
> > So, to consider why this is legal/verifiable, consider all the bad
> > things that method like ToString() might do with it.  If it tries to
> > cache that arg0 in a field of type 'Object', the value will be boxed
> > (a copy made, on the heap)... fair enough.  If it tries to copy arg0
> > into a field of type 'Int32', it will be dereferenced and
> > bitwise-copied... again, no problemo.
> >
> > So, the lesson here is that pointers are not evil (unverifiable)
> > inandof themselves.  It's what can be *done* with a pointer that's
> > evil and potentially unverifiable.  Make sense?
> >
> > As long as the bytecode verifier can see that it's impossible for the
> > pointer to be copied to a place where it may outlast its
> > destination... it's all good.
> >
> > Cheers,
> > -Shawn
> > http://msdn.com/tabletpc
> > http://windojitsu.com
> >
> > ===================================
> > This list is hosted by DevelopMentor�  http://www.develop.com
> > Some .NET courses you may be interested in:
> >
> > Essential .NET: building applications and components with C#
> > November 29 - December 3, in Los Angeles
> > http://www.develop.com/courses/edotnet
> >
> > View archives and manage your subscription(s) at
> http://discuss.develop.com
> >
>
> ===================================
> This list is hosted by DevelopMentor�  http://www.develop.com
> Some .NET courses you may be interested in:
>
> Essential .NET: building applications and components with C#
> November 29 - December 3, in Los Angeles
> http://www.develop.com/courses/edotnet
>
> View archives and manage your subscription(s) at
http://discuss.develop.com
>


-- Cheers, -Shawn http://msdn.com/tabletpc http://windojitsu.com

===================================
This list is hosted by DevelopMentor�  http://www.develop.com
Some .NET courses you may be interested in:

Essential .NET: building applications and components with C#
November 29 - December 3, in Los Angeles
http://www.develop.com/courses/edotnet

View archives and manage your subscription(s) at http://discuss.develop.com

_________________________________________________________________ Choose what you want to read. Protect your mail from spam. http://server1.msn.co.in/sp04/hotmailspamcontrol/ Win the war in 9 steps!

===================================
This list is hosted by DevelopMentor�  http://www.develop.com
Some .NET courses you may be interested in:

Essential .NET: building applications and components with C#
November 29 - December 3, in Los Angeles
http://www.develop.com/courses/edotnet

View archives and manage your subscription(s) at http://discuss.develop.com

Reply via email to