Creating a Managed C Application

Creating a Managed C++ Application

As discussed in Chapter 1, "C++, Visual C++, and Managed C++: What's the Difference?" a managed C++ application is fundamentally different from an unmanaged C++ application. The C++ code compiles not to machine code that can execute directly, but to an assembly of Intermediate Language, or IL. The assembly is kept in a file with an extension of .EXE or .DLL, but the content of the file is nothing like a traditional executable or DLL. Instead it holds IL and metadata , information about the classes in the assembly. To run the application, you actually ask the runtime to run it for you. The runtime loads the assembly, performing some security checks, and then calls a method in a class that the assembly holds. For console applications like those in this chapter, it calls the main() function, which is disguised as _tmain() in your source because some behind-the-scenes code is taking your character set into account. When any method or function in an assembly is called for the first time, it is compiled Just-In-Time (some say it is jitted ) to machine code. This machine code is cached to be used the next time this method is called. The machine code executes inside the runtime and is watched as it runs.

Managed applications can use the libraries that are provided with the .NET Framework, and can call methods of classes written in other .NET-supported languages without any special keywords or techniques. The runtime handles all the marshalling and conversion that is necessary to call from one language into another. As a result, most programmers are more productive in managed C++ than in unmanaged C++, especially when developing a product that integrates a variety of components . When testing a class written in managed C++, it's best to write your test harness in managed C++, so as not to incur any performance penalties for the transition between managed and unmanaged code.

Even though a managed console application is very different from an unmanaged console application, the process of creating them feels very much the same. Visual Studio takes care of the work behind the scenes for you. Here's what you do:

1. Open Visual Studio .NET 2003, if it's not already open .

2. On the Start Page, click New Project. If the Start Page isn't visible, choose File, New, Project.

3. Select the Visual C++ Projects folder on the left and Console Application (.NET) on the right.

4. Enter ManagedConsole as the project name (as shown in Figure 2.5), and click OK.

   Figure 2.5. Creating a .NET console application called ManagedConsole.

   

The wizard generates the skeleton of a managed C++ application. Remove the comment that starts TODO and edit the line that was generated for you so that it reads

 Console::WriteLine(S"Hello from a managed application"); 

Build the project by choosing Build, Build Solution. Run it by choosing Debug, Start without Debugging. You should see output like Figure 2.6.

Figure 2.6. A console application running on the .NET Framework looks just like an unmanaged console application.

Although this might feel a lot like creating the unmanaged console application from earlier in this chapter, there are some obvious differences. Bring up the solution view and expand the References folder under the ManagedConsole project. In the unmanaged console application, FirstConsole , there were no entries in the References folder. In this managed console application, there are three: System.Data , System , and mscorlib . Each of these entries names an assembly that implements a part of the .NET Framework and the Base Class Libraries. When an assembly is named as a reference, the classes defined in it are available to all of the classes defined in this project.

In addition, the generated code in ManagedConsole.cpp contains this line:

 #using <mscorlib.dll> 

This line of code makes the classes in mscorlib.dll available to the code in the main function. It's redundant, because a reference has already been added to mscorlib , but the wizard generates it anyway.

The classes in the Base Class Libraries are divided into namespaces to make them easier to document and understand. For example, the Console class is in the System namespace. Its full name is therefore System::Console . This line of code lets you refer to it, and all the other classes in the System namespace, without including the namespace name ( System ):

 using namespace System; 

There is really only one line in the main function, _tmain() :

 Console::WriteLine(S"Hello from a managed application"); 

The WriteLine() member function of the Console class takes a managed reference to an instance of the String class in the System namespace, System::String . An ordinary C-style string, as represented by characters in double quotes, is not an instance of a System::String . The S macro in this line of code converts from a C-style string to a System::String reference that can be passed to Console::WriteLine() . As you might guess from the name, the method writes text, followed by a line break, to the console screen.

Now that you know how to create, compile, and run a simple console application in managed C++, you can do a tremendous amount of programming for the .NET Framework. You can define classes, and then write code to create instances of the class and call their methods. You can write and test hundreds of thousands of lines of code in this way, just by adding lines to the main function (defined as _tmain in Visual C++) that is generated when you create a .NET console application with the project wizard.

These applications all require the .NET Framework and leverage the functionality of the .NET Base Class Libraries. They can also use libraries, such as MFC and ATL, that don't require the framework. (Accessing legacy libraries is covered in Chapter 6.) The most common use of a managed console application is to test a managed class, designed as part of a class library and to be used from any .NET-supported language.