In general, the CLR supports two different types: value types and reference types. Value types represent values allocated on the stack. They cannot be null and must always contain some data. When value types are passed into a function, they are passed by value, meaning that a copy of the value is made prior to function execution. This implies that the original value won’t change, no matter what happens to the copy during the function call. Since intrinsic types are small in size and don’t consume much memory, the resource cost of making a copy is negligible and outweighs the performance drawbacks of object management and garbage collection. Value types include primitives, structures, and enumerations; examples of which are shown in the following C# code listing:

int i;                     // primitive
struct Point { int x, y; } // structure
enum State { Off, On }     // enumeration

You can also create a value type by deriving a class from System.ValueType. One thing to note is that a value type is sealed, meaning that once you have derived a class from System.ValueType, no one else can derive from your class.

If a type consumes significant memory resources, then a reference type provides more benefits over a value type. Reference types (including objects, interfaces, and pointers) are so called because they contain references to heap-based objects and can be null. These types are passed by reference, meaning that when you pass such an object into a function, an address of or pointer to the object is passed—not a copy of the object, as in the case of a value type. Since you are passing a reference, the caller will see whatever the called function does to your object. The first benefit here is that a reference type can be used as an output parameter, but the second benefit is that you don’t waste extra resources because a copy is not made. If your object is large (consuming lots of memory), then reference types are a better choice. In .NET, one drawback of a reference type is that it must be allocated on the managed heap, which means it requires more CPU cycles because it must be managed and garbage-collected by the CLR. In .NET, the closest concept to destruction is finalization, but unlike destructors in C++, finalization is nondeterministic. In other words, you don’t know when finalization will happen because it occurs when the garbage collector executes (by default, when the system runs out of memory). Since finalization is nondeterministic, another drawback of reference types is that if reference-type objects hold on to expensive resources that will be released during finalization, system performance will degrade because the resources won’t be released until these objects are garbage-collected. Reference types include classes, interfaces, arrays, and delegates; examples of which are shown in the following C# code listing:

class Car {}             // class
interface ISteering {}   // interface
int[] a = new int[5];    // array
delegate void Process(  ); // delegate

Classes, interfaces, and delegates will be discussed shortly.

Microsoft .NET supports value types for performance reasons, but everything in .NET is ultimately an object. In fact, all primitive types have corresponding classes in the .NET Framework. For example, int is in fact an alias of System.Int32, and System.Int32 happens to derive from System.ValueType, meaning that it is a value type. Value types are allocated on the stack by default, but they can always be converted into a heap-based reference-type object, called boxing. The following code snippet shows that we can create a box and copy the value of i into it:

int i = 1;         // i - a value object
object box = i;    // box - a reference object

When you box a value, you get an object upon which you can invoke methods, properties, and events. For example, once you have converted the integer into an object, as shown in this code snippet, you can call methods that are defined in System.Object, including ToString( ), Equals( ), and so forth.

The reverse of boxing is of course unboxing , which means that you can convert a heap-based reference-type object into its value-type equivalent, as shown here:

int j = (int)box;

This example simply uses the cast operator to cast a heap-based object called box into a value-type integer.

The CLR provides full support for object-oriented concepts (such as encapsulation, inheritance, and polymorphism) and class features (such as methods, fields, static members, visibility, accessibility, nested types, and so forth). In addition, the CLR supports new features that are nonexistent in many traditional object-oriented programming languages, including properties, indexers, and events.^[11] Events are covered in Chapter 8. For now let’s briefly talk about properties and indexers.

A property is similar to a field (a member variable), with the exception that there is a getter and a setter method, as follows:

public class Car
{
  private string make;public string Make 
                    {
                      get { return make; }
                      set { make = value; }
                    }
}

Car c = new Car(  );
c.Make = "Acura";  // use setter
String s = c.Make; // use getter

Although this is probably the first time you’ve seen such syntax, this example is straightforward and really needs no explanation, with the exception of the keyword value . This is a special keyword that represents the one and only argument to the setter method.

Syntactically similar to a property, an indexer is analogous to operator[] in C++, as it allows array-like access to the contents of an object. In other words, it allows you to access an object like you’re accessing an array, as shown in the following example:

public class Car
{
  private string[] wheels;public string this[int index] 
  {
    get { return wheels[index]; }
    set { wheels[index] = value; }
  }
}

Car c = new Car(  );
c[0] = "LeftWheel";  // c[0] can be an l-value or an r-value

Here’s one note before we leave this topic: unlike C++ but similar to Java, classes in .NET support only single-implementation inheritance.

Interfaces support exactly the same concept as a C++ abstract base class (ABC) with only pure virtual functions. An ABC is a class that declares one or more pure virtual functions and thus cannot be instantiated. If you know COM or Java, interfaces in .NET are conceptually equivalent to a COM or Java interface. You specify them, but you don’t implement them. A class that derives from your interface must implement your interface. An interface may contain methods, properties, indexers, and events. In .NET, a class can derive from multiple interfaces.

One of the most powerful features of C is its support for function pointers. Function pointers allow you to build software with hooks that can be implemented by someone else. In fact, function pointers allow many people to build expandable or customizable software. Microsoft .NET supports a type-safe version of function pointers, called delegates. Here’s an example that may take a few minutes to sink in, but once you get it, you’ll realize that it’s really simple:

using System;
class TestDelegate 
{// 1. Define callback prototype
  delegate void MsgHandler(string strMsg);

  // 2. Define callback method
  void OnMsg(string strMsg)
  {
    Console.WriteLine(strMsg);
  }

  public static void Main(  ) 
  {
    TestDelegate t = new TestDelegate(  );

    // 3. Wire up our callback method
    MsgHandler f = new MsgHandler(t.OnMsg);

    // 4. Invoke the callback method indirectly
    f("Hello, Delegate.");
  }
}

The first thing to do is to define a callback function prototype, and the important keyword here is delegate, which tells the compiler that you want an object-oriented function pointer. Under the hood, the compiler generates a nested class, MessageHandler, which derives from System.MulticastDelegate.^[12] A multicast delegate supports many receivers, as opposed to a single-cast delegate (supported by System.Delegate), which is a base class of System.MulticastDelegate. Once you’ve defined your prototype, you must define and implement a method with a signature that matches your prototype. Then, simply wire up the callback method by passing the function to the delegate’s constructor, as shown in this code listing. Finally, invoke your callback indirectly. Having gone over delegates, you should note that delegates form the foundation of events, which are discussed in Chapter 8.