Search:   Namespaces Discussions .NET v1.1 Feedback

Boxing Messages   Related Types This message was discovered on microsoft.public.dotnet.general. Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions. Post a new message to this list... SK What is the real use of boxing and unboxing in what situations will it be used. Since all types are utlmately dereived from object..what is the need for boxing and unboxing.....help Reply to this message...        Niki Estner "SK" <Click here to reveal e-mail address> wrote in news:9dd801c48682$a1c18020$Click here to reveal e-mail address... [Original message clipped] Of course all value types are derived from object, that's what makes boxing possible from a language perspective. But (without boxing) value types always live on the stack and reference types always live on the heap: If you want to get a value type on the heap, you need a "reference type box" around it, that's why it's called boxing. Niki Reply to this message...        Jon Skeet [C# MVP] (VIP) Niki Estner <Click here to reveal e-mail address> wrote: [Original message clipped] There's actually some extra complexity there. The value type itself *doesn't* derive from System.Object. The boxed value type derived from System.Object (via System.ValueType). The two types have the same name. It's all a bit odd - see section 8.2.4 of the CIL spec for more information. However, it's up to the language itself to define the boxing conversions it wants to implement. [Original message clipped] Not true. For instance: public class Test { int i = 5; static void Main() { Test t = new Test(); } } That has created a value type within the Test type. The object itself (containing the value type value) is on the heap. See http://www.pobox.com/~skeet/csharp/memory.html -- Jon Skeet - <Click here to reveal e-mail address> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Reply to this message...        Niki Estner "Jon Skeet [C# MVP]" <Click here to reveal e-mail address> wrote in news:Click here to reveal e-mail address... [Original message clipped] I should have mentioned that I was talking about *high-level* language perspective, like C# or VB.net. [Original message clipped] :-) I assume you know what I meant. Niki Reply to this message...        Jon Skeet [C# MVP] (VIP) Niki Estner <Click here to reveal e-mail address> wrote: [Original message clipped] <snip> > I assume you know what I meant. Yup, but others don't necessarily. The reason I wrote the memory page in the first place is that people say "Value types are always stored on the stack" and then people reading that get (understandably, IMO) confused as to where value type members of reference types actually *do* live. -- Jon Skeet - <Click here to reveal e-mail address> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Reply to this message...        Jon Skeet [C# MVP] (VIP) SK <Click here to reveal e-mail address> wrote: [Original message clipped] Boxing and unboxing makes it much easier to deal with value types in situations where what is expected is a reference type. For instance, it is boxing which allows us to add an int to an ArrayList, or set the value in a DataRow to a float, etc. -- Jon Skeet - <Click here to reveal e-mail address> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Reply to this message...        Sijin Joseph Yes all types are derived from Object, but types that derive from System.ValueType (aka value type) objects have different memory semantics. Normal(reference) types in .Net are allocated memory on the managed heap, whereas value types are allocated menory on the stack. That is why there needs to be boxing, when a reference type object is expected and we pass a value type, the runtime automatically allocates memory on the heap and copies the value of the value type into the new object. Sijin Joseph http://www.indiangeek.net http://weblogs.asp.net/sjoseph SK wrote: [Original message clipped] Reply to this message...        Jon Skeet [C# MVP] (VIP) Sijin Joseph <Click here to reveal e-mail address> wrote: [Original message clipped] That's an oversimplification which isn't really true. See http://www.pobox.com/~skeet/csharp/memory.html -- Jon Skeet - <Click here to reveal e-mail address> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Reply to this message...        Sijin Joseph That's a great article Jon! I sure did miss the part where Value types are fields of Reference types. But one question comes to mind, in this case will boxing occur? (since the value is already on the heap) Sijin Joseph http://www.indiangeek.net http://weblogs.asp.net/sjoseph Jon Skeet [C# MVP] wrote: [Original message clipped] Reply to this message...        Jon Skeet [C# MVP] (VIP) Sijin Joseph <Click here to reveal e-mail address> wrote: [Original message clipped] No. Boxing occurs when you need to view a value type as a reference type - it's sort of when a value type value needs to be on the heap "on its own" rather than as part of another object. -- Jon Skeet - <Click here to reveal e-mail address> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Reply to this message...        Sijin Joseph Hi Jon, Although i am sure that internally no boxing takes place in this case, but surprisingly the compiler does generate the box instruction. I compiles this code     class Class1     {         /// <summary>         /// The main entry point for the application.         /// </summary>         [STAThread]         static void Main(string[] args)         {             Test t = new Test();             ArrayList al = new ArrayList();             al.Add(t.a);         }     }     public class Test     {         public int a = 5;     } and i got this IL ..method private hidebysig static void Main(string[] args) cil managed { .entrypoint .custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 ) // Code size 31 (0x1f) .maxstack 2 .locals init ([0] class ConsoleApplication1.Test t, [1] class [mscorlib]System.Collections.ArrayList al) IL_0000: newobj instance void ConsoleApplication1.Test::.ctor() IL_0005: stloc.0 IL_0006: newobj instance void [mscorlib]System.Collections.ArrayList::.ctor() IL_000b: stloc.1 IL_000c: ldloc.1 IL_000d: ldloc.0 IL_000e: ldfld int32 ConsoleApplication1.Test::a IL_0013: box [mscorlib]System.Int32 // Box call is generated IL_0018: callvirt instance int32 [mscorlib]System.Collections.ArrayList::Add(object) IL_001d: pop IL_001e: ret } // end of method Class1::Main Sijin Joseph http://www.indiangeek.net http://weblogs.asp.net/sjoseph Jon Skeet [C# MVP] wrote: [Original message clipped] Reply to this message...        Jon Skeet [C# MVP] (VIP) Sijin Joseph <Click here to reveal e-mail address> wrote: [Original message clipped] There's nothing surprising about a box happening here - adding an int to an ArrayList will always box, as it's got to store it in an object for the ArrayList to work. (Note that ArrayList.Add takes object, not int.) You'll see the same thing if you just try al.Add(5); -- Jon Skeet - <Click here to reveal e-mail address> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Reply to this message...        Sijin Joseph Well it's surprising because 't.a' is already on the heap, since it is part of a reference type. What would be intresting is to see if the boxing is actually taking place, although the box instruction is being generated, is the JITer is actually creating a new object on the heap to store the value. It would be intresting to look at the rotor sources to check the same. Sijin Joseph http://www.indiangeek.net http://weblogs.asp.net/sjoseph Jon Skeet [C# MVP] wrote: [Original message clipped] Reply to this message...        Jon Skeet [C# MVP] (VIP) Sijin Joseph <Click here to reveal e-mail address> wrote: [Original message clipped] Yes, but it's not a separate object. Note that al.Add isn't taking "t.a" as the parameter - it's taking the *value* of t.a as the parameter. [Original message clipped] The CLR *must* create a new object on the heap. Your instance of Test is eligible for garbage collection, which means there must be another copy of the data somewhere, and it must be on the heap. -- Jon Skeet - <Click here to reveal e-mail address> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Reply to this message...     System.Collections.ArrayList System.Data.DataRow System.Int32 System.Object System.STAThreadAttribute System.ValueType Ad MBR BootFX Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT

Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd. Contact Us - Terms of Use - Privacy Policy - www.dotnet247.com