- C#
- C# Types
- Visual Basic.NET
- C++ with Managed Extensions
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
C++ with Managed Extensions
C++ is a very popular language, one that's been in wide use for more than a dozen years. Providing some way to use C++ with the .NET Framework is essential. Yet the semantics of C++ don't exactly match those of the CLR. They have much in common—both are object-oriented, for example—but there are also many differences. C++, for instance, supports multiple inheritance, the ability of a class to inherit simultaneously from two or more parent classes, while the CLR does not.
Visual Basic 6 also differs substantially from the CLR, but Microsoft owns Visual Basic. The company was free to change it as they wished, and so VB.NET was designed to match the CLR. Microsoft does not own C++, however. Unilaterally changing the language to match the CLR would have met with howls of protest. Yet providing no way to create .NET Framework–based applications in C++ would also have left many developers very unhappy. What's the solution?
The answer Microsoft chose was to create a set of extensions to the base C++ language. Officially known as Managed Extensions for C++, the resulting dialect is commonly referred to as just Managed C++. C++ is not simple to begin with, and Managed C++ adds new complexities. The goal of this chapter's final section is to provide an overview of the changes wrought by Managed C++.
Before looking at a Managed C++ example, it's useful to describe some of the extensions made to the language. In particular, several keywords have been added to allow access to CLR services, all of which begin with two underscores. (This follows
Managed C++ or C#?
C++ has legions of die-hard fans. And why shouldn't it? It's a powerful, flexible tool for building all kinds of applications. It's complicated, too, which means that learning to exploit all that power and flexibility takes a substantial amount of effort. Anyone who's put in the time to master C++ is bound to be less than thrilled about leaving it behind.
Yet for brand-new applications built from scratch on the .NET Framework, C++ probably should be left behind. For a C++ developer, learning C# isn't difficult. In fact, learning C# will probably be easier than using Managed C++ to write .NET Framework–based applications. As the short summary in this chapter suggests, Managed C++ adds even more complexity to an already complex language. For new applications, C# is probably a better choice.
For extending existing C++ applications with managed code, however, Managed C++ is a good choice. And if you plan to port an existing C++ application to run on the Framework, Managed C++ is also a good choice, since it saves you from rewriting large parts of your code. Although it's not as important in the .NET Framework world as either VB.NET or C#, Managed C++ is nevertheless a significant member of .NET's language arsenal. the convention defined in the ANSI standard for C++ extensions.) Among the most important of these are the following.
__gc: Indicates that a type is subject to garbage collection. In other words, this keyword means that the type being declared is a CTS reference type. Managed C++ allows this keyword to be applied to classes, arrays, and other types.
__value: Indicates that a type is not subject to garbage collection; that is, that the type is a CTS value type.
__interface: Used to define a CTS interface type.
__box: An operation that converts a CTS value type to a reference type.
__unbox: An operation that converts a boxed CTS value type back to its original form.
__delegate: Used to define a CTS delegate type.
Given this brief introduction, we can now make some sense out of an example.
A Managed C++ Example
C# and VB.NET were both designed for the CLR, while C++ was not. As a result, code written in Managed C++ can look a bit odd. Here's the same example shown earlier in this chapter, this time in Managed C++:
// A Managed C++ example
# include "stdafx.h"
# using <mscorlib.dll>
__gc __interface IMath
{
int Factorial(int f);
double SquareRoot(double s);
};
__gc class Compute : public 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);
}
};
void main(void)
{
Compute *c = new Compute;
int v;
v = 5;
System::Console::WriteLine("{0} factorial: {1}",
__box(v), __box(c->Factorial(v)));
System::Console::WriteLine("Square root of {0}:
{1:f4}",
__box(v), __box(c->SquareRoot(v)));
}
The first thing to notice is how much this example resembles the C# version. Most of the basic syntax and many of the operators are the same. Yet it's different, too, beginning with the #include and #using statements necessary for creating managed code in C++. Following these, the interface IMath is defined, just as before. This time, however, it uses the __interface keyword and precedes it with the __gc keyword. The result is a C++ incarnation of a CTS-defined interface.
Next comes the class Compute, which implements the IMath interface. This class too is declared with the __gc keyword, which means that it's a CTS class with a lifetime managed by the CLR rather than the developer. The class varies a bit in syntax from the C# example, since C++ doesn't express things in exactly the same way, but it's nonetheless very similar.
The example ends with a standard C++ main function. Just like before, it creates an instance of the Compute class, then calls its two methods, all using standard C++ syntax. The only substantive difference is in the calls to WriteLine. Because this method expects reference parameters, the __box operator must be used to correctly pass the numeric parameters. Boxing also occurred for this parameter in C# and VB.NET, but it was done automatically. Because C++ was not originally built for the CLR, however, the developer must explicitly request this operation. Finally, just as you'd expect, the output of this example is the same as before: the factorial and square root of five.
Managed C++ Types
Managed C++ allows full access to the .NET Framework, including the types defined by the CLR and more. It's important to note that managed and unmanaged code, classes defined with and without __gc, can be defined in the same file, and they can exist in the same running process. Only the managed classes are subject to garbage collection, however; unmanaged classes must be explicitly freed as usual in C++. Table 4-3 shows some of the major CLR types and their equivalents in Managed C++.
Other Managed C++ Features
Because it fully supports the CLR, there's much more in Managed C++. Delegates can be created using the __delegate keyword, while namespaces can be referenced with a using namespace statement, such as
using namespace System;
Exceptions can be handled using try/catch blocks, and custom CLR exceptions can be created that inherit from System::Exception. Attributes can also be embedded in code using the same syntax as in C#.
Table 4-3 Some CLR Types and Their Managed C++ Equivalents
|
CLR |
Managed C++ |
|
Byte |
unsigned char |
|
Char |
wchar_t |
|
Int16 |
short |
|
Int32 |
int, long |
|
Int64 |
__int64 |
|
UInt16 |
unsigned short |
|
UInt32 |
unsigned int, unsigned long |
|
UInt64 |
unsigned __int64 |
|
Single |
float |
|
Double |
double |
|
Decimal |
Decimal |
|
Boolean |
bool |
|
Structure |
struct |
|
String |
String* |
|
Class |
__gc class |
|
Interface |
__gc __interface |
|
Delegate |
__delegate |
Managed C++ is a major extension to the C++ environment provided by Visual Studio.NET, but it's not the only new feature. This latest edition of Microsoft's flagship development tool also includes better support for building traditional applications, including COM-based applications. Except for C++, all languages in Visual Studio.NET compile only to MSIL, and so require the .NET Framework to run. Since all Managed C++ classes are compiled to MSIL, the language can obviously be used to generate Framework-based code, but C++ is unique in that it also allows compiling directly to a machine-specific
Is C++ a Dead Language?
C++ has been the workhorse of professional software developers for most of the last decade. It's been used to write Lotus Notes, a surfeit of business applications, and even parts of Windows. Yet in a world that offers C#, VB.NET, and Java, where does C++ fit? Has its usefulness come to an end?
Certainly not. C#, VB.NET, and Java are much better than C++ for many types of applications, even many for which C++ has commonly been used. But all three of these languages operate in a virtual machine environment. This has many benefits, but there's also a substantial price: performance and size. Some categories of applications, especially system-level software, can't afford this. Who's going to build an operating system in a garbage-collected language? Who wants to build embedded applications for memory-constrained devices in a language that requires a large supporting runtime library?
The day when C++ was the default choice for building a broad range of new applications is over. In the Microsoft world, C# and VB.NET will be the new defaults, while Java dominates elsewhere. Yet in cases where none of these is appropriate—and they do exist—C++ will still dominate. Its role will surely shrink, probably substantially, but C++ is not about to disappear.
binary. For building applications that don't require the CLR, C++ is the only way to go.