Boxing in C# has little to do with Saturday night television but quite a bit more with that part-time job at the warehouse you had as a student. It is an important concept in C# that is related to how the compiler handles different kinds of variables in memory. Knowing how the compiler handles the various types allows you to avoid unexpected side effects in your code.

This article explains what boxing is, how it works and how it can negatively effect your code if you don’t pay attention to it. We also look at how generics can be used to improve your code’s efficiency. And we try to answer the ultimate question: Is everything in C# an object?

Everything is an object in C# .. but not all objects are created equally

In C#, everything inherits from System.Object, so they share all the common object methods :

string a = “hello world”;
int b = 34;
Console.WriteLine( “{0} {1}”,a.ToString(),b.ToString());

At first glance all objects look the same in C#. But an important distinction is made between value types and reference types. Value types are basic types such as struct, int, long, short etc. Reference types are all the classes you will use (strings, delegates, objects)

• Value types (int,struct..) etc are located on the stack. (unless they are part of a reference type, such as a class)
• Reference types (classes…) are accessed through a pointer to their actual location on the heap.

We simplify things a little for this article: The stack keeps track of what is executing in our application. As we enter and exit methods items are added to or removed from the top. The heap stores all the applications data, and since data can be added to and removed from it randomly it needs to be garbage collected.

Why the difference ? The stack is faster to access for the runtime so by putting simple types close at hand the code gains in efficiency.

Assigning variables

The graphic shows four possible scenarios :

1. Boxing: When you assign an integer to an object (object b=a): a new managed memory block is created on the heap. For this C# has to allocate memory at runtime.
2. By Value: If you copy the integer to another integer (int c=a) the value is simply copied to another memory slot on the stack (which is allocated at compile time), this is the fastest assignment as most checks can be done at compile time.
3. Unboxing: When you cast an object to a value type (d=(int)b) the result is stored on the stack. This is also an expensive operation as at runtime the value has to be retrieved from the heap and is then checked to see if the cast was valid. (If the source argument is null or a reference to an incompatible object, an InvalidCastException is thrown.)
4. By Reference: Classes are reference types so if you assign a new object to an older object (object e = b) no new instance is created, the object pointer on the stack simply points to the older object. A direct result of this is that if you modify either b or e, they will both reflect the change as they both point to the same location in memory.

Boxing is as simply putting a basic type in wrapper (making it a fully blown object), and unboxing taking that wrapped object and converts it back to a simpler type. To do the boxing managed memory needs to be allocated on the heap, references need to be updated, and the contents of the value type have to be copied.

Value types are copied, reference types just refer to the original object

The following code example shows how a simple change in code can have very different results.

    class MainClass
    {
        struct Demo
        {
            public int x;
            public Demo(int x)
            {
                this.x = x;
            }
        }

        public static void Main(string[] args)
        {
            Demo p = new Demo(10);
            object box = p;
            p.x = 20;
            Console.Write(((Demo)box).x);
        }
    }

   class MainClass
    {
        class Demo
        {
            public int x;
            public Demo(int x)
            {
                this.x = x;
            }
        }

        public static void Main(string[] args)
        {
            Demo p = new Demo(10);
            object reference = p;
            p.x = 20;
            Console.Write(((Demo)reference).x);
        }
    }

In Example A, because Demo is a struct (and thus a value type on the stack) when we box it a copy is made. When we modify the original no change is made to the copy.

In Example B, we have created Demo as a class. In this situation we can assign it to another object and we don’t need to box it. A reference is made instead. So when we update the original, the copy is also updated as they both point to the same location in memory.

Boxing and unboxing value types slows things down

Often you can’t rely on what the type of variable a function will take so you need to use an object variable as object is the lowest common denominator in .NET. In the following example we use the ArrayList class to store a set of integers. The ArrayList can store any type of variable, but to be able to do this it accept the object class.

        using System.Collections;

        public static void Main(string[] args)
        {
            int total = 0;
            ArrayList myList = new ArrayList();
            for (int Lp = 0; Lp < 10000000; Lp++)
                myList.Add(Lp); // Box: Integer to an object
            foreach(object item in myList)
                total += (int)item; // Unbox: Object to integer
        }

When we add an integer to the Arraylist it is boxed into an object, and when we retrieve it it is unboxed back into an integer.

Note that this is only an issue if we are trying to store value types in the arraylist. If we were trying to store objects (eg. classes) there is no boxing done, as the original type was an object already. In this situation a simple reference is stored. On retrieval there is no unboxing necessary as only a reference is returned.

Boxing in Action

When we look at our code in a dissassembler the boxing operation is clearly visible in the output stream:

; myList.Add(Lp); // Box: Integer to an object
IL_000f: ldloc.1
IL_0010: ldloc.2
IL_0011: box [mscorlib]System.Int32
IL_0016: callvirt instance int32 class [mscorlib]System.Collections.ArrayList::Add(object)

And when we convert the object back to an integer the reverse happens:

; total += (int)item; // Unbox: Object to integer
IL_0042: unbox [mscorlib]System.Int32

Generics remove the need to box and unbox value types

In .NET 2.0 generics and generic collections were introduced that remove the need to box and unbox variables in many common situations. The following example is functionally equivalent to the earlier boxing example. We use a generic here, but force it to be “object”:

        using System.Collections.Generic;
        public static void Main(string[] args)
        {
            int total = 0;
            List<object> myList = new List<object>();
            for (int Lp = 0; Lp < 10000000; Lp++)
                myList.Add((object)Lp); // We need a boxing operation
            foreach(int item in myList)
                total += (int)item; // Unbox back to an int
        }

The above example of course makes little sense because we are inefficient on purpose. I included it to demonstrate how with generics we can get around the need for boxing with generic collections.

        using System.Collections.Generic;
        public static void Main(string[] args)
        {
            int total = 0;
            List<int> myList = new List<int>();
            for (int Lp = 0; Lp < 10000000; Lp++)
                myList.Add(Lp); // No need to box things
            foreach(int item in myList)
                total += item; // No need to unbox
        }

Generic are similar to templates in C++, they allow you to specify a type and the compiler will generate all the required code. In our example we specify that our list is of type int, so the compiler will create a List class that supports integers. There is no longer a need to convert our integer type to an object first. If you would like to know more about how generics work have a look at another post I wrote on the subject: Generics in C# .

So how much of a difference does boxing make?

Boxing is slower but how much is the difference and do you need to care? To put things into perspective I tested the timing on the three code examples above. For this I used .NET’s Stopwatch class to measure the code’s performance. First of all, the .NET runtime is pretty fast and I found that I needed to set the loop iterations at some 10 milion before I was able to get a consistent result across runs.

• Boxing/Unboxing ListArray example: 2580 ms
• Boxing/Unboxing List<object> example: 2050ms
• Non boxing List<int> example: 825 ms

The non boxing List<int> example is about 2.5 times faster than List<object>, which is quite considerable.

To finish up…

Based on this should you rewrite all your code to implement generics? Probably not unless you have several tight loops that could use your attention, note that this only applies to value types (structs, ints) . For reference types (i.e. all classes) this is less of a problem as they are stored as a reference anyway.

It is however a good idea to implement generics in any code you write from here on. Not just because of the potential gains in speed but also because generics provide the compiler with much more information.

• Generics reduce the number of coding errors as you have compile-time checking of types
• Generics are more readable, you don’t need to cast all over the place and it’s always obvious what type it is associated with

Also if possible avoid passing value types as parameters to methods if these force a conversion to an object.

Image credit: Wall of boxed by celesteh

This is a post from Martijn's C# Coding Blog.

In this post I look at how we can simply retrieve basic information about our own types, discover their methods and lastly how we can import a foreign assembly, inspect its contents, load a class and execute its methods.

When C# compiles your code it not only stores the program in the assembly but the complete information on each of the structures you have defined. Each class, its types, parameters and methods described into detail are all available. This might sound like stating the obvious, but until recently most compilers treated this kind of “meta” data as a waste of space and never included it into the final assembly.

Through reflection C# offers a way of inspecting this meta information from a running program. The program reflects on itself to discover itself. It can use this to change the way it runs, or to report the results back to the user.

Why is this useful? If you distribute an application that accepts third plug-ins you need some kind of mechanism to inspect whether the supplied plug-in provides the correct set of methods for your code to work with. Very similar to how Visual Studio works with plug-ins.

Type

To be able to interact with their own code C# programs rely heavily on the Type class. The Type class can represent all C# type declarations: class types, interface types, array types, value types, enumeration types, type parameters etc. You can use it to query a type and discover what kind of contents it has.

GetType() is the most common way to access C# reflection and I’ll show in the next example how you can find out the original type of an object after it has been cast down to a basic object. The GetType() method is inherited from object, so each C# object has access to it. As can be expected, GetType() returns an instance of the Type class.

But first have a look a simple example of how we can use GetType()

    using System;
    using System.Reflection;
    class MainClass
    {
        // This routine takes an object, which is the root of all
        // types in C#
        public static void PrintType(object Data)
        {
            Console.WriteLine("Type of Data: {0}",Data.GetType());
        }

        public static void Main(string[] args)
        {
            string msg = "Hello World";
            PrintType(msg);
            int    theValue = 1024;
            PrintType(theValue);
        }
    }

This will print:

Type of Data: System.String
Type of Data: System.Int32

If you know that the object you were passed was really a System.Int32 object, you can could cast it back and modify it as a regular integer. The following works but isn’t very nice:

         object Test = new int();

         // This only works if the above object is an integer
         if (Test.GetType().ToString()=="System.Int32")
            {
                int MyInt = (System.Int32) Test;
                MyInt = 20;
            }

A much better way of course in your own code to do the following:

         object Test = new int();
         if (Test is int)
            {
                int MyInt = (int) Test;
                MyInt = 20;
            }

The TypeOf operator

The typeof() operator works in similar fashion at GetType but on type definitions at compile time. The GetType() operator works on instances of variables and is available at run-time. The benefit is that you don’t have to instantiate a class to obtain an type instance. To illustrate the difference have a look at the following:

Type e = typeof(MyExampleClass);

// This is the same as:

MyClass example = new MyExampleClass();
Type t = example.GetType();

Using Type to query a class methods and members

Of course we can obtain much more information about a class than just its name. We can use the GetMethods() method to obtain a list of all the methods in the class, and GetMembers() to obtain all its member variables. Not only that, we can also call these members after we discover them.

using System;
using System.Reflection;

namespace Reflection
{
    class MySecretClass
    {
        public int Z;

        public int Add(int x) { return x+1; }
        public int Sub(int x) { return x-1; }

         MySecretClass()
        {
            Z = 0;
        }
    }

    class MainClass
    {
        public static void Main(string[] args)
        {
         Type t = typeof(MySecretClass);

         MethodInfo[] MethodArray = t.GetMethods();
         foreach (MethodInfo Method in MethodArray)
          Console.WriteLine("Method: {0}",Method.ToString());

         MemberInfo[] MemberArray = t.GetMembers();
         foreach (MemberInfo Member in MemberArray)
          Console.WriteLine("Member: {0}",Member.ToString());

        }
    }
}

Loading an external assembly

Inspecting our own types is not nearly as adventurous as trying to decode the definitions found in a assembly you are trying to understand or validate. The following code loads the “mscorlib.dll” (which is the present in all .NET environments) and prints its name, version, culture and public key:

            System.Reflection.Assembly LoadedAssembly = System.Reflection.Assembly.Load("mscorlib.dll");
            System.Console.WriteLine(LoadedAssembly.GetName());

We can query the assembly for a couple of basic variables, such as its name, location etc:

            Console.WriteLine("Full Name: {0}", LoadedAssembly.FullName);
            Console.WriteLine("Location: {0}", LoadedAssembly.Location);
            Console.WriteLine("Code Base: {0}", LoadedAssembly.CodeBase);
            Console.WriteLine("Escaped Code Base: {0}", LoadedAssembly.EscapedCodeBase);
            Console.WriteLine("Loaded from GAC: {0}", LoadedAssembly.GlobalAssemblyCache);

Now the assembly is in memory we can explore it using the above introduced Type class, the GetTypes() method returns an array of all types in the assembly. The full code that queries the mscorlib.dll in detail is below:

using System;
using System.Reflection;

namespace Reflection
{
    class MainClass
    {

        public static void Main(string[] args)
        {
            System.Reflection.Assembly LoadedAssembly = System.Reflection.Assembly.Load("mscorlib.dll");
            System.Console.WriteLine(LoadedAssembly.GetName());

            Console.WriteLine("Full Name: {0}", LoadedAssembly.FullName);
            Console.WriteLine("Location: {0}", LoadedAssembly.Location);
            Console.WriteLine("Code Base: {0}", LoadedAssembly.CodeBase);
            Console.WriteLine("Escaped Code Base: {0}", LoadedAssembly.EscapedCodeBase);
            Console.WriteLine("Loaded from GAC: {0}", LoadedAssembly.GlobalAssemblyCache);

            Type[] types = LoadedAssembly.GetTypes();

            foreach (Type t in types)
            {
                Console.WriteLine ("Name: {0}", t.FullName);
                Console.WriteLine ("Namespace: {0}", t.Namespace);
            }
        }
    }
}

Calling dynamically bound assemblies at runtime

After we have loaded an assembly we want to execute some code in it. In the above example we used the mscorelib.dll because it conveniently is available on all .NET systems. In the following example I show how you can create an object instance and call a named method.

The System.DateTime class is one of many stored in this dll, and we are interested in the ToLongDateString method. Normally we would call it in a manner similar to the below:

System.DateTime myTime   = new System.DateTime(2000,1,1,12,0,0);
Console.WriteLine("Current Time: {0}",myTime.ToLongDateString());

As we have loaded mscorlib dynamically we need to go through some more steps to locate the method and constructor we are interested in:

object myObject = LoadedAssembly.CreateInstance("System.DateTime",false,BindingFlags.ExactBinding,null,new Object[] {2000,1,1,12,0,0},null,null);

We use CreateInstance to create an instance of the class we require, “System.DateTime”. Just ignore the other parameters for now; the second important one is where we pass an object array containing the exact number of variables to match the correct constructor.

Next we need to obtain a handle to the method inside the class we want to invoke.

MethodInfo m = LoadedAssembly.GetType("System.DateTime").GetMethod("ToLongDateString");

We execute the method by calling “Invoke”, passing our object and an object array of parameters (null as ToLongDateString does not take any). We need to cast the resulting object to a string.

string result = (string) m.Invoke(myObject,null);
Console.WriteLine("The time and date: {0}",result);

From the above it is clear that calling methods from a dynamically loaded and bound assembly is considerably more work. It does however allow you to extend your program through third party extensions, or by enabling functionality through assemblies that might not be available on all systems.

The full code for the final example is below:

using System;
using System.Reflection;

namespace Reflection
{
        class MainClass
        {

                public static void Main(string[] args)
                {
                        System.Reflection.Assembly LoadedAssembly = System.Reflection.Assembly.Load("mscorlib.dll");
                        System.Console.WriteLine(LoadedAssembly.GetName());

                        // Doing it the statically bound way
                        System.DateTime myTime   = new System.DateTime(2000,1,1,12,0,0);
                        Console.WriteLine("Current Time: {0}",myTime.ToLongDateString());

                        // And now through an assembly loaded at runtime
                        object myObject = LoadedAssembly.CreateInstance("System.DateTime",false,BindingFlags.ExactBinding,null,new Object[] {2000,1,1,12,0,0},null,null);

                        MethodInfo m = LoadedAssembly.GetType("System.DateTime").GetMethod("ToLongDateString");
                        string result = (string) m.Invoke(myObject,null);
                        Console.WriteLine("The time and date: {0}",result);

                }
        }
}

Image credit: Mike Baird

This is a post from Martijn's C# Coding Blog.