Previous Page
Next Page

Unboxing

Because a variable of type object can refer to a boxed copy of a value, it's only reasonable to allow you to get at that boxed value through the variable. You might expect to be able to access the boxed int value that a variable o refers to by using a simple assignment statement such as:

int i = o;

However, if you try this syntax, you'll get a compile time error. If you think about it, it's pretty sensible that you can't use the int i = o; syntax. After all, o could be referencing absolutely anything and not just an int. Consider what would happen in the following code if this statement was allowed:

Circle c = new Circle(); 
int i = 42; 
object o; 
 
o = c;  // o refers to a circle 
i = o;  // what is stored in i?

To obtain the value of the boxed copy, you must use what is known as a cast, an operation that checks that it is safe to convert one type to another, and then does the conversion. You prefix the object variable with the name of the type, in parentheses, as in this example:

int i = 42; 
object o = i;  // boxes 
i = (int)o;    // compiles okay

The effect of this cast is subtle. The compiler notices that you've specified the type int in the cast. Next, the compiler generates code to check what o actually refers to, at runtime. It could be absolutely anything. Just because your cast says o refers to an int, that doesn't mean it actually does. If o really does refer to a boxed int and everything matches, the cast succeeds and the compiler-generated code extracts the value from the boxed int. (In this example, the boxed value is then used to initialize i.) This is called unboxing. The following diagram shows what is happening:

Graphic

However, if o does not refer to a boxed int there is a type mismatch, causing the cast to fail. The compiler-generated code throws an InvalidCastException at runtime. Here's an example of an unboxing cast that fails:

Circle c = new Circle(42); 
object o = c;        // doesn't box because Circle is a class 
int i = (int)o;      // compiles okay, but throws at runtime
Graphic
NOTE
The type you specify in the unboxing cast must exactly match the type actually in the box. For example, if the box holds a copy of an int and you try to unbox it into a long, you will get an InvalidCastException. The fact that there is a built-in implicit conversion from an int to a long is irrelevant. The match must be exact.

You will use boxing and unboxing in later exercises. Keep in mind that boxing and unboxing are expensive operations because of the amount of checking required, and the need to allocate additional heap memory. Boxing has its uses, but injudicious use can severely impair the performance of a program. You will see an alternative to boxing in Chapter 17, “Introducing Generics.”

Pointers and Unsafe Code

This section is purely for your information and is aimed at developers who are familiar with C or C++. If you are new to programming, feel free to skip this section!

If you have already developed in languages such as C or C++, much of the preceding discussion concerning object references might be familiar. Although neither C nor C++ have explicit reference types, both languages have a construct that provides similar functionality—pointers.

A pointer is a variable that holds the address of, or a reference to, an item in memory (on the heap or on the stack). A special syntax is used to identify a variable as a pointer. For example, the following statement declares the variable pi as a pointer to an integer:

int *pi;

Although the variable pi is declared as a pointer, it does not actually point anywhere until you initialize it. For example, to use pi to point to the integer variable i, you can use the following statements, and the & operator, which returns the address of a variable:

int *pi;
int i = 99; 
... 
pi = &i;

You can access and modify the value held in the variable i through the pointer variable pi like this:

*pi = 100;

This code updates the value of the variable i to 100, because pi points to the same memory location as the variable i.

One of the main problems that developers learning C and C++ have is understanding the syntax used by pointers. The * operator has at least two meanings (in addition to being the arithmetic multiplication operator), and there is often great confusion about when to use & rather than *. The other issue with pointers is that it is very easy to point somewhere invalid, or to forget to point somewhere at all, and then try to reference the data pointed to. The result will be either garbage or a program that fails with an error because the operating system detects an attempt to access an illegal address in memory. There is also a whole range of security flaws in many existing systems resulting from the mismanagement of pointers; some environments (not Microsoft Windows) fail to enforce checks that a pointer does not refer to memory that belongs to another process, opening up the possibility that confidential data could be compromised.

Reference variables were added to C# to avoid all these problems. If you really want to, you can continue to use pointers in C#, but you must mark the code as unsafe. The unsafe keyword can be used to mark a block of code, or an entire method, as shown here:

public static void Main(string [] args) 
{ 
    int x = 99, y = 100; 
    unsafe 
    { 
        swap (&x, &y); 
    } 
    Console.WriteLine("x is now {0}, y is now {1}", x, y); 
} 
 
public static unsafe void swap(int *a, int *b) 
{ 
    int temp; 
    temp = *a; 
    *a = *b; 
    *b = temp; 
}

When you compile programs containing unsafe code, you must specify the /unsafe option.

Unsafe code also has a bearing on how memory is managed; objects created in unsafe code are said to be unmanaged. We discuss this issue in more detail in Chapter 13.

In this chapter, you have learned some important differences between value types that hold their value directly on the stack and reference types that refer indirectly to their objects on the heap. You have also learned how to use the ref and out keywords on method parameters to gain access to the arguments. You have seen how assigning a variable of the System.Object class to a value (such as 42) causes the variable to refer to a boxed copy of the value made on the heap. You have seen how assigning a variable of a value type to a variable of the System.Object class causes the boxed copy to refer to a variable of a value type (such as int).


Previous Page
Next Page