.NET Languages
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Common Language Runtime is explicitly designed to support multiple languages. In general, though, languages built on the CLR tend to have a good deal in common. By defining a large set of core semantics, the CLR also defines a large part of a typical programming language built using it. For example, a substantial chunk of learning any CLR-based language is seeing how the standard types defined by the CLR are mapped into that language. You must also learn the language's syntax, of course, including the control structures the language provides. Yet once you know what the CLR offers, you're a long way down the path to learning any language built on top of it.
This chapter describes C# and Visual Basic.NET, the most important CLR-based languages. It also takes a brief look at the Managed Extensions for C++ that allow C++ developers to write CLR-based code. The goal is not to provide exhaustive coverage of every language feature—that would require three more books—but rather to give you a sense of how these languages look and of how they express the core functionality provided by the CLR.
What about Java for the .NET Framework?
In the fall of 2001, Microsoft announced Visual J#.NET, an implementation of the Java language built on the CLR. Despite this, I doubt that Java will ever be a viable choice for the .NET Framework. The reason is that even if a Java aficionado chooses to use a CLR-based Java compiler, such as Visual J#.NET, she's unlikely to be truly happy. Java implies a group of libraries and interfaces such as Swing and Enterprise JavaBeans. The .NET Framework provides its own equivalent technologies, and so most of these won't be available. As a result, a developer using the Java language on the .NET Framework won't feel like she's working in a true Java environment because the familiar libraries won't be there.
The real target market for Visual J#.NET is Microsoft's existing Visual J++ customers. By providing a migration path to the .NET Framework, Microsoft is helping them move away from a dying platform to one with a long future ahead of it. People who believe that Microsoft is truly interested in building a first-class environment for building new Java applications might also wish to examine their beliefs about Santa Claus.
The battle lines are clear: It's .NET versus the Java world. This is unquestionably a good thing. Those who think everyone should implement Java forget both the dangers of monopoly and the sloth that comes with having no competition. Having two powerful technology camps, each with a strong position, is the ideal world. Each has innovations that the other can learn from, and each provides examples of things to avoid. In the end, the competition makes both of them better.
C#
As its name suggests, C# is a member of the C family of programming languages. Unlike C, C# is explicitly object-oriented. Unlike C++, however, which is the most widely used object-oriented language in this family, C# isn't fiendishly complicated. Instead, C# was designed to be easily approachable by anyone with a background in C++ or Java.
The most popular tool today for creating C# code is Microsoft's Visual Studio.NET. It's not the only choice, however. Microsoft also provides a command-line compiler with the .NET
Framework called csc.exe, and the open source world has also created a C# compiler. Visual Studio.NET provides a rich environment for building CLR-based applications in C#, however, so it's hard to imagine that other alternatives will attract a large share of developers.
Standardizing C# and the CLR
Microsoft has submitted C# and a subset of the CLR called the Common Language Infrastructure (CLI) to the international standards body ECMA, where they are on track to become ECMA standards. Along with C#, the things that have been submitted for standardization include the syntax and semantics for meta-data, MSIL (rechristened the Common Intermediate Language, or CIL), and parts of the .NET Framework class library. For more details on exactly what has been submitted and its current status, see msdn.microsoft.com/net/ecma.
Sun came close to doing something similar with its Java technology, but backed away at the last minute. Will Microsoft's efforts be more successful? Sun resisted this step in large part because they were unwilling to give up control of Java. Control of Java is a valuable thing, and since Sun is a for-profit company, its reluctance to relinquish this control makes perfect sense. Microsoft is also a for-profit company. Will they really wait until ECMA has approved, say, an enhancement to C# before including it in their next release? And if they do, is this a good thing? Standards bodies aren't known for their speed.
I'd be surprised if Microsoft lets ECMA control the rate at which innovations appear in future releases of .NET technologies. Still, making C# and the CLI standards does give others a way to build them. Somewhat surprisingly, given its traditional antipathy toward Microsoft, the open source world has spawned various efforts to build parts of .NET. The most visible of these is the Mono project. (Mono means "monkey" in Spanish, which may be an oblique commentary on the Mono team's view of Microsoft.) Mono's ambitious goal is to implement at least a large part of what Microsoft has given to ECMA, including a C# compiler and the CLI, and perhaps more. Mono's creators say that they were attracted to the CLR for technical reasons, which must please Microsoft. In fact, from Mono's perspective, the CLI is the specification of a system while .NET's CLR is just the Microsoft implementation of this specification. Mono is certainly an interesting undertaking; to learn more about it, see http://www.go-mono.com.
Microsoft itself, together with Corel, has announced plans to make an implementation of C# and the CLI available for BSD UNIX. As discussed in Chapter 1, Microsoft faces substantial credibility problems in porting the .NET Framework to non-Windows platforms. Still, it's early in the game, and anything is possible. Whatever happens, having public standards and an open source implementation for their core technologies will certainly be a new experience for Microsoft.
A C# Example
Like most programming languages, C# defines data types, control structures, and more. Unlike older languages, however, C# does this by building on the CLR. Understanding the CLR therefore takes one a long way toward understanding C#. To illustrate this, here's a simple C# example:
// A C# example
interface IMath
{
int Factorial(int f);
double SquareRoot(double s);
}
class Compute : IMath
{
public int Factorial(int f)
{
int i;
int result = 1;
for (i=2; i<=f; i++)
result = result * i;
return result;
}
public double SquareRoot(double s)
{
return System.Math.Sqrt(s);
}
}
class DisplayValues
{
static void Main()
{
Compute c = new Compute();
int v;
v = 5;
System.Console.WriteLine("{0} factorial:
{1}", v, c.Factorial(v));
System.Console.WriteLine("Square root of {0}:
{1:f4}", v, c.SquareRoot(v));
}
}
The program begins with a comment, indicated by two slashes, giving a brief description of the program's purpose. The body of the program consists of three types: an interface named IMath and the two classes Compute and DisplayValues. All C# programs consist of some number of types, the outermost of which must be classes, interfaces, structures, enums, or delegates. (Namespaces, discussed later, can also appear here.) All methods, fields, and other type members must belong to one of these types, which means that C# doesn't allow either global variables or global methods.
The IMath interface, which is a C# incarnation of the Common Type System (CTS) interface type described in Chapter 3, defines the methods Factorial and SquareRoot. Each of these methods takes one parameter and returns a numeric result. These parameters are passed by value, the default in C#. This means that changes made to the parameter's value within the method won't be seen by the caller once the method returns. Placing the keyword ref in front of a parameter causes a parameter to be passed by reference, so any changes made within the method will be reflected back to the caller.
Each class in this example is also a C# incarnation of the underlying CTS type. C# classes can implement one or more interfaces, inherit from at most one other class, and do all of the other things defined for a CTS class. The first class shown here, Compute, implements the IMath interface, as indicated by the colon between Compute and IMath. Accordingly, this class must contain implementations for both of the interface's methods. The body of the Factorial method declares a pair of integer variables, initializes the second of them to 1, then uses a simple for loop to calculate the factorial of its parameter (and doesn't bother to check for overflow, which is admittedly bad programming practice). Compute's second method, SquareRoot, is even simpler. It relies on the .NET Framework class library, calling the Sqrt function provided by the Math class in the System namespace.
The last type in this simple example, the class DisplayValues, contains only a single method named Main. Much like C and C++, a C# program begins executing with this method in whatever type it appears. Although it's not shown here, Main can take arguments passed in when the program is started, and it must be declared as static. In this example, Main returns void, which is C#'s way of saying that the method has no return value. The type void cannot be used for parameters as in C and C++, however. Instead, its only purpose is to indicate that a method returns no value.
In this example, Main creates an instance of the Compute class using C#'s new operator. When this program is executed, new will be translated into the MSIL instruction newobj described in the Chapter 3. Main next declares an int variable and sets its value to 5. This value is then passed as a parameter into calls to the Factorial and SquareRoot methods provided by the Compute instance. Factorial expects an int, which is exactly what's passed in this call, but SquareRoot expects a double. The int will automatically be converted into a double, since this conversion can be done with no loss of information. C# calls this an implicit conversion, distinguishing it from type conversions that are marked explicitly in the code.
The results are written out using the WriteLine method of the Console class, another standard part of the .NET Framework's System namespace. This method uses numbers wrapped in curly braces that correspond to the variables to be output. Note that in the second call to WriteLine, the number in braces is followed by ":f4". This formatting directive means that the value should be written as a fixed-point number with four places to the right of the decimal. Accordingly, the output of this simple program is
5 factorial: 120 Square root of 5: 2.2361
The goal of this example is give you a feeling for the general structure and style of C#. There's much more to the language, as the next sections illustrate.