To make the switch from C to C++, a new file extension was used. As you can see in the preceding HelloWorld3.cpp example, the file extension for C++/CLI applications remains unchanged. However, there is still a need to distinguish between C++ compilation and C++/CLI compilation—the result of native C++ compilation is native code, whereas the result of C++/CLI compilation is managed code. If you try to compile the code on the command line, as shown in the following, you'll get compiler errors.
These errors will complain that System is neither a class nor a namespace name, and that the identifier WriteLine is not found. Both the namespace System and the method WriteLine are the managed aspects of your code. The Visual C++ compiler can act as a normal C++ compiler or as a C++/CLI compiler. By default, it remains a native compiler. To use it as a C++/CLI compiler, you use the compiler switch /clr, as in the following command line:
CL.EXE /clr HelloWorld3.cpp
This simple HelloWorld3 application shows one of the advantages that C++/CLI has over all other commonly used .NET languages: it provides source code compatibility with a good old native language.
C++/CLI is a superset of the C++ language. A valid C++ program is also a valid C++/CLI program. As a consequence, your existing code base is not lost. Instead of reimplementing existing applications with a completely new language and programming infrastructure, you can seamlessly extend existing code with .NET features.
The HelloWorld3.exe file created by the C++/CLI compiler and linker is a so-called .NET assembly. For this chapter, it is sufficient to consider assemblies as the deployable units of the .NET world. Chapter 4 will provide a more detailed definition of this term. The HelloWorld3.exe assembly differs from assemblies created by other .NET languages because it contains native code as well as managed code. An assembly like HelloWorld3.exe is also called a mixed-code assembly.
A migration strategy based on C++/CLI can preserve huge investments in existing C++ source code. This is extremely important because there is a vast amount of C++ code that is already written, tested, accepted, and in service. Furthermore, this strategy allows a partial migration with small iterations. Instead of switching everything to .NET in one chunk, you can flexibly use different .NET features when they seem appropriate.
Was this article helpful?