CTS Delegate Types

Delegates are the .NET equivalent of a type-safe, C-style function pointer. The key difference is that a
.NET delegate is a class that derives from System.MulticastDelegate, rather than a simple pointer to a
raw memory address. In C#, delegates are declared using the delegate keyword.
// This C# delegate type can "point to" any method
// returning an int and taking two ints as input.
delegate int BinaryOp(int x, int y);Delegates are useful when you wish to provide a way for one entity to forward a call to another
entity and provide the foundation for the .NET event architecture. As you will see in Chapters 11 and 19,
delegates have intrinsic support for multicasting (i.e., forwarding a request to multiple recipients) and
asynchronous method invocations (i.e., invoking the method on a secondary thread).

CTS Enumeration Types

Enumerations are a handy programming construct that allow you to group name/value pairs. For
example, assume you are creating a video game application that allows the player to select one of three
character categories (Wizard, Fighter, or Thief). Rather than keeping track of simple numerical values to
represent each possibility, you could build a custom enumeration using the enum keyword.
// A C# enumeration type.
enum CharacterType
{
Wizard = 100,
Fighter = 200,
Thief = 300
}
By default, the storage used to hold each item is a 32-bit integer; however, it is possible to alter this
storage slot if need be (e.g., when programming for a low-memory device such as a Windows mobile
device). Also, the CTS demands that enumerated types derive from a common base class, System.Enum.
As you will see in Chapter 4, this base class defines a number of interesting members that allow you to
extract, manipulate, and transform the underlying name/value pairs programmatically.

CTS Structure Types

The concept of a structure is also formalized under the CTS. If you have a C background, you should be
pleased to know that these user-defined types (UDTs) have survived in the world of .NET (although they
behave a bit differently under the hood). Simply put, a structure can be thought of as a lightweight class
type having value-based semantics. For more details on the subtleties of structures, see Chapter 4.
Typically, structures are best suited for modeling geometric and mathematical data and are created in
C# using the struct keyword.// A C# structure type.
struct Point
{
// Structures can contain fields.
public int xPos, yPos;
// Structures can contain parameterized constructors.
public Point(int x, int y)
{ xPos = x; yPos = y;}
// Structures may define methods.
public void PrintPosition()
{
Console.WriteLine("({0}, {1})", xPos, yPos);
}
}

CTS Interface Types

Interfaces are nothing more than a named collection of abstract member definitions, which may be
supported (i.e., implemented) by a given class or structure. In C#, interface types are defined using the
interface keyword. By convention, all .NET interfaces begin with a capital letter I, as in the following
example:
// A C# interface type is usually
// declared as public, to allow types in other
// assemblies to implement their behavior.
public interface IDraw
{
void Draw();
}
On their own, interfaces are of little use. However, when a class or structure implements a given
interface in its unique way, you are able to request access to the supplied functionality using an interface
reference in a polymorphic manner.

Benefits of CIL

At this point, you might be wondering exactly what is gained by compiling source code into CIL rather
than directly to a specific instruction set. One benefit is language integration. As you have already seen,
each .NET-aware compiler produces nearly identical CIL instructions. Therefore, all languages are able
to interact within a well-defined binary arena.Furthermore, given that CIL is platform-agnostic, the .NET Framework itself is platform-agnostic,
providing the same benefits Java developers have grown accustomed to (e.g., a single code base running
on numerous operating systems). In fact, there is an international standard for the C# language, and a
large subset of the .NET platform and implementations already exist for many non-Windows operating
systems (more details at the conclusion of this chapter). In contrast to Java, however, .NET allows you to
build applications using your language of choice.

The Role of the Common Intermediate Language

Let’s examine CIL code, type metadata, and the assembly manifest in a bit more detail. CIL is a language
that sits above any particular platform-specific instruction set. For example, the following C# code
models a trivial calculator. Don’t concern yourself with the exact syntax for now, but do notice the
format of the Add() method in the Calc class.
// Calc.cs
using System;
namespace CalculatorExample
{
// This class contains the app's entry point.
class Program
{
static void Main()
{
Calc c = new Calc();
int ans = c.Add(10, 84);
Console.WriteLine("10 + 84 is {0}.", ans);
// Wait for user to press the Enter key before shutting down.

Console.ReadLine();
}
}
// The C# calculator.
class Calc
{
public int Add(int x, int y)
{ return x + y; }
}
}
Once you compile this code file using the C# compiler (csc.exe), you end up with a single-file *.exe
assembly that contains a manifest, CIL instructions, and metadata describing each aspect of the Calc
and Program classes.

Introducing the Building Blocks of the .NET Platform (the CLR, CTS, and CLS)

Now that you know some of the benefits provided by .NET, let’s preview three key (and interrelated)
entities that make it all possible: the CLR, CTS, and CLS. From a programmer’s point of view, .NET can
be understood as a runtime environment and a comprehensive base class library. The runtime layer is
properly referred to as the Common Language Runtime, or CLR. The primary role of the CLR is to locate,
load, and manage .NET types on your behalf. The CLR also takes care of a number of low-level details
such as memory management, application hosting, handling threads, and performing various security
checks.
Another building block of the .NET platform is the Common Type System, or CTS. The CTS
specification fully describes all possible data types and programming constructs supported by the
runtime, specifies how these entities can interact with each other, and details how they are represented
in the .NET metadata format (more information on metadata later in this chapter; see Chapter 15 for
complete details).
Understand that a given .NET-aware language might not support each and every feature defined by
the CTS. The Common Language Specification, or CLS, is a related specification that defines a subset of
common types and programming constructs that all .NET programming languages can agree on. Thus, if
you build .NET types that only expose CLS-compliant features, you can rest assured that all .NET-awarelanguages can consume them. Conversely, if you make use of a data type or programming construct that
is outside of the bounds of the CLS, you cannot guarantee that every .NET programming language can
interact with your .NET code library. Thankfully, as you will see later in this chapter, it is very simple to
tell your C# compiler to check all of your code for CLS compliance.