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
