< C++ .Net Framework | Main | C++ .Net Early Stages 2 >



Early Stages of the C++ .Net 1

(Managed Extensions for C++)



In this module you will be introduced to the new keywords that used for the Managed Extension of C++. Keep in mind that these new keywords are deprecated in new C++ .Net syntax. It is used during the migration period from native C++ to the C++ .Net.

  1. New Keywords in Visual C++ .NET for Managed Extensions C++

Note: This topic valid for Visual C++ .Net 2003 and if compiled using Visual C++ .Net 2005 you need to use the /clr:oldSyntax option).


To allow you to distinguish between code written for the .NET runtime and code that will not be managed by the runtime, Microsoft has introduced extensions to the C++ language with the keywords in the following Table. The most important new compiler switch is /clr. This switch tells the compiler to compile all code to Microsoft intermediate language (MSIL), regardless of whether the code is managed by the .NET garbage collector. The following Table lists those new keywords used for Managed Extension of C++ .Net. In new C++ (VC++ 2005), these keywords already deprecated.



Managed Extension for C++ Keyword



Indicates that the class is abstract, that is, not all methods have an implementation, and to use the class, you must derive from it.


Used to box a value type. Boxing creates an object with the value of the value type that has been boxed.


Declares a delegate type. Delegates are essentially type-safe function pointers.


Declares an event, a notification mechanism as part of a class. This keyword indicates that the class can generate the event, and it adds code to store the delegates invoked when the event is raised.


Identifies that a class is managed by the .NET garbage collector or that a pointer points to a managed object.


Used when the name of a type or member is a keyword in C++ and indicates to the compiler to ignore the C++ meaning of the word.


When combined with the __gc keyword, the __interface keyword allows you to declare a managed interface.


Used to indicate that the type is not managed by the .NET garbage collector or to indicate that a pointer points to a non–managed object.


Used on a pointer to pin the object it points to. This pinning means that for the scope of the pointer the object will not be moved in the managed heap during garbage collection.


Indicates that a method is the get() or set() method for a property.


Used on a class to indicate that the class is complete and cannot be extended through class derivation.


This cast operator performs a run-time type check and throws a managed exception if the cast fails.


Operator used to obtain the Type object for a particular type.


Indicates that the type is lightweight and is created on the stack rather than on the managed heap.


New keywords in C++ to support Managed Code


When you use the /clr compiler switch, you also should have the following #using statement somewhere in the project and typically at the beginning of the program.

#using <mscorlib.dll>

This statement has two functions:


  1. First, it gives access to the metadata in the identified assembly, which means that you can use the public types defined in the assembly.

  2. Second, #using indicates to the linker to generate metadata in the output assembly to identify the assemblies that the output assembly uses.

Every assembly must use the types in mscorlib, and that’s why you must include the previous #using <mscorlib.dll> statement. Notice that the name given in the #using statement is the name of the file that contains the metadata, not the name of the assembly. The complete name of an assembly contains the culture, version, and public key token, as well as the short assembly name. If available, all of this information for an assembly that your assembly depends upon must be added to the dependent’s manifest. If you are likely to use an assembly that will be installed in the global assembly cache (GAC) - a container for shared assemblies, then it is important that the correct, full name of the assembly is placed in the assembly that you are creating.


Net Framework 2.0 Configuration snap-in


.Net Framework 2.0 Configuration snap-in


The Assembly folder that contains assemblies


The assembly folder that contains assemblies


There can be several versions of an assembly in the GAC, so the .NET Fusion technology uses metadata in the dependent assembly to determine which version to load. Fusion is the system that handles locating and binding to assemblies. The #using statement does not look in the GAC for a metadata container, so you have to give the name of (and possibly the full path to) a copy of this assembly outside of the GAC. The system assemblies (mscorlib, System, System::Windows::Forms, and so on) are installed in the GAC, but there are copies of their DLLs in the .NET Framework folder in the %SYSTEMROOT% folder. The #using statement checks this folder automatically. The #using statement takes the name of the metadata container in either angle brackets or quotes; it does not matter which you use. If you specify a path, the compiler will use this information to locate the metadata. The exception is the mscorlib assembly. If you provide a path to the mscorlib.dll file, the compiler will ignore your path information. The search order is:


  1. The full path specified in #using.

  2. The current working folder.

  3. The .NET Framework folder in %SYSTEMROOT%.

  4. The folders mentioned on the command line with the /AI compiler switch.

  5. The folders mentioned in the LIBPATH environment variable.

The .Net Framework folder. Notice the .Net versions, 1.0.x, 1.1.x and 2.0.x


The .Net Framework folder. Notice the .Net versions, 1.0.x, 1.1.x and 2.0.x





The .NET Fusion technology uses specific rules (probing) to locate assemblies at run time. The #using search order is not the same as the Fusion probing rules. Note that #using takes the name of a file that contains metadata rather than saying that you must provide an assembly. Metadata can be found in assemblies, modules, and .obj files and you can specify any of these files with #using. If you provide the name of an assembly, the details of the assembly will be added to the manifest of the assembly you are creating, so Fusion will be able to probe for, and bind to, the assembly at run time. Provide the name of a module when you intend to use types in the imported module in your assembly and you want the module to be part of your assembly. As a consequence, the manifest of the assembly you are creating will have metadata for the module. Finally, you can use an .obj file in the #using directive. Whenever you compile a source file, the .obj file will have metadata for the types in the .obj file. If you want to use the types in an .obj file, the file will also have to be linked to the assembly that you are creating. In this respect, #using is similar to #include for native C++. When you specify a library assembly with #using, you will get access to only the public types defined in the assembly. If you use #using on an .obj file, you will have access to both public and private types.





Executables are assemblies in .NET and can export types. However, don’t be tempted to use #using on an executable. Although the C++ compiler will compile the code, the .NET runtime will complain when your code runs because when it loads the assembly, the runtime will see that the assembly is not a library assembly (a DLL) and will throw a BadImageFormatException exception. To compile C++ to MSIL, the compiler must be invoked with the /clr switch. The #using <mscorlib.dll> statement and the /clr switch go hand in hand - if you have one, you have to use the other. This switch tells the compiler that the code should be compiled as MSIL. All managed code will be compiled as MSIL, but most native (non-managed) code will also be compiled as MSIL. This means that if you have classes that will be created on the unmanaged C++ heap, the code will still be MSIL and will be run by the .NET runtime. There are exceptions, but essentially all code will be compiled to MSIL.



Part 1 | Part 2



< C++ .Net Framework | Main | C++ .Net Early Stages 2 >