Experience the modern language features of Visual C + + 2005 (2)

New Interop

Of all the. NET Framework languages in Visual Studio. NET 2003, Visual C + + 2005 provides the best interop functionality. It's not like an armchair, and now has the ability to implement real-world scenarios, and one of the best examples is porting Quake II to the. NET framework platform, and Visual C + + 2005 expands this functionality.

In the local and managed world,. NET has four main ways to interop. Interop for COM can use the RCW (Runtime callable Wrappers) and the CCW (COM callable Wrappers), while the CLR is primarily responsible for type scheduling (except in rare cases, the custom scheduler is used). But these calls are huge overhead. Because interfaces are extremely complex, you must be extra cautious, otherwise you will cause serious performance losses and ensure that the underlying components of these wrappers are the latest version. This means that when you try to introduce a lot of local COM code, COM interop is useful only for some simple situations.

The second way to use Interop is through P/invok, typically by using the DllImport property, specifying this attribute on the method declaration on the function to be introduced, and how it is specified according to the declaration, thus determining how the schedule is handled. However, DllImport can only work if a DLL has an output function through the export attribute.

If you want to invoke managed code from your local code, you can select a CLR host. In this case, the local program must do all the work: Set the host, bind the runtime, start the host, retrieve the appropriate AppDomain, set the invocation context, locate the required assemblies and classes, and invoke the action on the appropriate class. This is everything that a robust solution needs to do, it's tedious and requires a lot of manual code.

The fourth, and probably the easiest and most efficient approach, is to use Interop in C + +, by setting/clr, the compiler will generate MSIL code-not local machine code, which includes functions that use inline assembler and CPU-specific instruction sets, such as sse;/ The CLR is exactly the Quake II transplant. NET platform is the key point. There is no need to add any other binary code, but simply include some corresponding header files, managed C + + can and local C + + call each other, for developers, do not need to do any work to achieve this, why not? In fact, the compiler handles the creation of the corresponding converter and travels back and forth between the hosting and the local two worlds.

For C + + developers, the results are more relevant, one of which is the notorious hybrid DLL loading problem in Visual Studio. NET 2002 and Visual Studio. NET 2003. If you run the local code in the loader lock (loader lock) but also reference a managed type that is not loaded in the assembly, the CLR invokes LoadLibrary to load the assembly. LoadLibrary will attempt to get the loader lock at this point, causing the program to deadlock. This problem, in a new version of Visual Studio, has been resolved.

Although/CLR has great benefits for C + + developers, there are some downsides. As mentioned earlier,/CLR generates an image file that contains both local and managed code, which can sometimes cause problems. First, these mixed image files do not comply with the CLI, and they have local entry points, which can result in severe conversion performance losses when the managed boundary is exceeded. But most importantly, local entry points can have a serious impact on tools that use assembly and reflection (reflection). To examine an image file before reflection, you must load and run the assembly before reflection can examine the metadata until all the initialization is complete, and the reflection does not load a managed assembly correctly because it contains a local entry point.

In addition, Visual Studio. NET 2003 can generate verifiable code in rare cases, even if it is generated, and it takes a lot of effort. However, MSIL provides the first class of support for unverifiable directives (pointer algorithms, indirect loading, access to the local heap), and verifiable code allows you to participate in trusted computing, which in turn enriches the capabilities of Visual Studio 2005. Click Deployment is based on local trustworthy computing, just as managed code is hosted in SQL Server 2005. One of the primary goals of the Visual C + + 2005 development Group is to enable the compiler to generate a mixed and verifiable image, introducing two new compiler options:/clr:pure and/clr:safe, but before studying the two new options, you need to figure out the C + + How interop Works.