< Old To New C++ .Net 9 | Main | Visual C++ .Net Migration 2 >



Managed Extensions for C++ to

New C++ .NET Syntax Migration 1



In this module we will see more tasks need to be done in order to fully updating your old, Managed Extension for C++ code to the new C++ .Net code. All the new keywords, operators etc. used in the new C++ .Net are discussed here. The code snippets used in this module if any, are the mix of Visual C++ .Net 2003 and 2005. If the old code used on VC++ 2005, compile with the /clr:OldSyntax option. The following are the topics in this module.

  1. Managed Extensions for C++ Upgrade To new C++ Syntax Checklist

  2. To Update Managed Extensions for C++ Code

  3. /clr (Common Language Runtime Compilation)


  1. Safe and Pure Images

  2. Metadata and Unnamed Classes

  3. Pure and Verifiable Code

  4. Pure (/clr:pure)

  5. Advantages of /clr:pure

  6. Limitations of /clr:pure

  7. Verifiable (/clr:safe)

  8. How To: Migrate to /clr

  9. Compile with Visual C++ 2005

  10. Versions Prior to Visual C++ 2003

  11. Upgrading from Visual C++ 2003

  12. Upgrading from Managed Extensions for C++

  13. Convert C Code to C++

  14. Reconfigure Project Settings

  15. Create New Project Configurations

  16. Change Project Settings

  17. Precompiled Headers



  1. Fixing Errors

  2. Metadata Merge

  3. Loader Lock Deadlock

  4. Data Exports

  5. Type Visibility

  6. Floating Point and Alignment Issues

  7. COM Initialization

  8. Performance Issues

  9. Program Crashes on Shutdown

  10. Using New C++ Features

  11. New C++ Language Features

  12. CLR Data Type Keywords

  13. Override Specifiers

  14. Keywords for Generics

  15. Miscellaneous New Keywords

  16. Non-Keyword Language Constructs

  17. New C++ Operators

  18. More CLR Constructs



Managed Extensions for C++ Upgrade To new C++ Syntax Checklist


The Visual C++ 2005 includes new features for targeting virtual machines with garbage collection, such as the .NET Framework. In a future release, support for Managed Extensions for C++ will be removed (dominant in Visual C++ .Net 2003). C++/CLI represents a dynamic component programming paradigm extension to the ISO-C++ standard language. Code using Managed Extensions for C++ can still be compiled with /clr:oldSyntax. This topic lists the syntactic differences between Managed Extensions for C++ and the new C++ syntax.


To Update Managed Extensions for C++ Code


Check and do the following tasks for updating the Managed Extension for C++ code to new C++ code.


  1. Remove #using <mscorlib.dll>. (This assembly is now referenced by default).

  2. Replace __gc class with ref class.

  3. Replace __gc struct with ref struct.

  4. Replace __value class with value class.

  5. Replace __value struct with value struct.

  6. Remove default constructors from value classes. (Default constructors for value types are allowed in Managed Extensions for C++, but the nature of the CLR prevents them from being called reliably, so this feature has been removed).

  7. Replace __gc __interface with interface class.

  8. Replace __abstract with abstract, and move it after the class name.

  9. Replace __sealed with sealed, and move it after the class name.

  10. Replace __property with interface class, combine the get and set methods into a single property block, and remove the trailing underbar/name suffix from these accessors. For simple properties, the accessors need not be defined explicitly. The syntax for indexed properties requires bracket pairs after the property type.

  11. Replace __event with event.

  12. Replace __value enum with enum class.

  13. Replace pointers to reference types followed (defined with __gc*) with ^.

  14. Replace pointers to values types that potentially live in the garbage collected heap with interior_ptr.

  15. Replace pointers declared with __pin with instances of pin_ptr, unless a whole object is being pinned, in which case use interior_ptr, and then use pin_ptr on the interior pointer. For Visual C++ 2005, this template is defined in the cli::language Namespace.

  16. Replace new with gcnew.

  17. Replace 0 or null with nullptr when used to indicate that a pointer or handle into the garbage collected heap does not indicate an object and when using comparisons to check pointers and handles.

  18. Update garbage-collected arrays declared with __gc[] to use the array type. For Visual C++ 2005, this template is defined in the cli::language Namespace.

  19. Remove all instances of __box (implicit Boxing.)

  20. Remove the "S" prefix from string literals (the compiler now determines if a string is literal based on the context in which it is used).

  21. Replace the explicit declaration and usage of overloaded operators required in Managed Extensions for C++ (such as op_Addition, op_Subtraction) with the traditional C++ syntax. The new syntax reverts to the traditional C++ using the operator keyword.

  22. Update conversion operators (which use op_Implicit and op_Explicit in Managed Extensions for C++ syntax).

  23. Replace __typeof with typeid.

  24. Replace __try_cast with safe_cast. For Visual C++ 2005, this template is defined in the cli::language Namespace.

  25. If you were signing your assembly (also known as giving your assembly a strong name) with the CLR's assembly-signing attributes, you should remove those attributes from your code and instead use the assembly-signing linker options.





/clr (Common Language Runtime Compilation)


This option enables applications and components to use features from the common language runtime (CLR). You can set this through the project property page as shown in the previous modules.





options - One or more of the following, separated by a comma.


/clr - Creates metadata for your application that can be consumed by other CLR applications, and allows your application to consume types and data in the metadata of other CLR components.


/clr:pure - Produces an MSIL-only output file with no native executable code, although it can contain native types compiled to MSIL.


/clr:safe - Produces an MSIL-only (no native executable code) and verifiable output file. /clr:safe enables verification diagnostics (PEVerify Tool -Peverify.exe).


/clr:oldSyntax - Enables Managed Extensions for C++ syntax, the original Visual C++ syntax for CLR programming. Managed Extensions for C++ syntax is deprecated in Microsoft Visual C++ 2005, You should only use /clr:oldSyntax if you are maintaining a Visual C++ application that uses Managed Extensions for C++. If you are developing a new application, use the updated syntax. If you have a Managed Extensions for C++ application, you can begin to port your project to use the new syntax.


/clr:noAssembly - Specifies that an assembly manifest should not be inserted into the output file. By default, noAssembly is not in effect, and an assembly manifest is inserted into the output file. A managed program that does not have an assembly metadata in the manifest is called a module. noAssembly can only be used when a DLL is the output file of the compilation. If you compile with /c (Compile Without Linking) and /clr:noAssembly, then specify the /NOASSEMBLY (Create a MSIL Module) option in the linker phase to create a module. noAssembly is deprecated in Visual C++ 2005. Use /LN (Create MSIL Module) instead. Before Visual C++ 2005, /clr:noAssembly implied /clr. However, /clr now also supports /clr:oldSyntax, so you must specify one /clr form when you specify /clr:noAssembly. For example, /clr:noAssembly /clr creates a module using the new Visual C++ CLR syntax and /clr:noAssembly, oldSyntax creates a module using Managed Extensions for C++. Before Visual C++ 2005, /clr:noAssembly required /LD. /LD is now implied with you specify /clr:noAssembly.


/clr:initialAppDomain - Allows a Visual C++ application to run on version 1 of the common language runtime. An application compiled with initialAppDomain should never be used by an application using ASP.NET. Upgrade to a newer runtime to do ASP.NET work with C++.


Table 1


Managed code is code that can be inspected and managed by the common language runtime. Managed code can access managed objects. An application compiled with /clr may or may not contain managed data. Only CLR types will be instantiated on the garbage-collected heap. To compile a function to native code, use the unmanaged pragma. By default, /clr is not in effect. When /clr is in effect, /MD is also in effect. /MD ensures that the dynamically linked, multithreaded versions of the runtime routines are selected from the standard header (.h) files. Multithreading is necessary for managed programming in part because the CLR garbage collector runs finalizers in an auxiliary thread. If you compile with /c, you can specify the CLR type (IJW, safe, or pure) of the resulting output file with /CLRIMAGETYPE (Specify Type of CLR Image). /clr implies /EHa, and no other /EH options are allowed with /clr. All modules passed to a given invocation of the linker must have been compiled with the same run-time library compiler option (/MD or /LD).

Use the /ASSEMBLYRESOURCE (Embed a Managed Resource) linker option to embed a resource in an assembly. /DELAYSIGN (Partially Sign an Assembly), /KEYCONTAINER (Specify a Key Container to Sign an Assembly), and /KEYFILE (Specify Key or Key Pair to Sign an Assembly) linker options also let you customize how an assembly is created. When /clr is used, the _MANAGED symbol is defined to be 1. The global variables in a native object files will be initialized first (during DllMain() if the executable is a DLL), and then the global variables in the managed section will be initialized (before any managed code is run). #pragma init_seg only affects the order of initialization within the managed and unmanaged categories.



Part 1 | Part 2 | Part 3 | Part 4



< Old To New C++ .Net 9 | Main | Visual C++ .Net Migration 2 >