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

It Just works

Interop technology in Visual Studio. NET 2003,c++ is called IJW or "It Just works" and has been replaced with a more appropriate "interop technology" in the new version. What is the working principle of it? For each local method in the program, the compiler generates both managed and unmanaged entry points, one of which is the implementation of the true method and the other is the forwarder, which can be converted and the necessary scheduling. A managed entry point is usually an implementation of a true method, unless the code cannot be interpreted as an MSIL or a developer using "#pragma unmanaged" to force the specified entry point to the implementation of the local machine code.

When a IJW forwarder works-such as forwarding to local code-the compiler provides the implementation of the transformation and invokes the actual implementation code through an offset or IAT (Import address Table), although for specially developed sample programs, A call to a forwarder consumes a clock cycle that drops to 10, but typically between 50 and 300 clock cycles. A managed P/invoke is used when the forwarder is MSIL, because the P/invoke is made up of a series of declarations and non-true code implementations, so that the CLR supports the transformation at run time, and the same forwarder implementation is only slightly slower than the local code.

As mentioned earlier, for each function, IJW has two entry points, managed and unmanaged, but their structure determines that the call to the entry point is determined at compile time (such as pointers and vtable). At compile time, the compiler does not know the runtime's call point hosting state, so which one does it choose? In Visual Studio. NET 2003, the compiler always chooses an unmanaged entry point so that when the caller is managed code, this creates a problem that we call "Double P/invoke," as shown in insert 4. In this case, the conversion of the unmanaged converter to the managed call, and the result is converted back into managed code.

Figure 2:double P/invoke problem
for this, Visual C + + 2005 provides some solutions, first of all, the keyword __clrcall, which specifies whether to publish unmanaged entry points, when the function declaration Adding this keyword prevents the unmanaged entry point from being generated (the disadvantage is that the function cannot be invoked directly from the local code later), and the keyword __clrcall can be added to the function pointer. Second, the double P/invoke, provided by Visual C + + 2005, is automatically eliminated by run-time checking and cookies, and by the runtime deciding whether an unmanaged converter can be skipped and forwarding the call directly to a managed entry point.

The Final solution is pure MSIL, and the new compiler option,/clr:pure, enables the compiler to generate a pure managed image that does not contain a local structure. In fact, it not only generates assemblies that comply with CLI standards, but also solves the double p/invoke problem by preventing the generation of unmanaged transformations. Thus, for each function, there is only one entry point-the managed entry point, because without the unmanaged entry point, the vtable and function pointers do not exist.

While code is compliant with the CLI standard, it does not necessarily mean that it is verifiable, and that it is important to be verifiable in those low trust environments, such as file sharing. To this end, Microsoft has introduced a stricter compiler option/clr:safe, which is a boon to C + + developers who need verifiable code. This option causes the compiler to generate an absolutely verifiable assembly, and any unverifiable program code structure can result in a compile-time error. For example, an attempt to compile a variable of an integer pointer will result in an error of "int* = This type is not verifiable" and indicate which line is in the code. All managed C + + code for SQL Server 2005 Storage Example Chengri must be compiled with this option.


Figure 3: Compilation mode
Figure 3 illustrates the managed and unmanaged data and code structures that are generated by different compiler options. If no/clr option is included, the local image is generated, and a mixed image containing managed and unmanaged code and data is generated using/clr. Pure MSIL, which is generated by the/clr:pure option, does not contain any unmanaged code, although there is no guarantee of verifiable and containing local data types. On platforms based on the. NET framework, security MSIL is an ideal choice for verifiable code; In short, these two new compilation patterns can be applied to different situations and can even accomplish tasks that previously seemed impossible or difficult to complete.