Effecitve C # principle 46: Minimizing interaction with other unmanaged code

In the development design. NET, one of the smartest changes Ms has made is that they realize that if there is no way to integrate existing code into the new. NET environment, no one will accept this new platform. Ms knows that if there is no way to exploit the existing code, this will prevent everyone from accepting it. Interacting with other unmanaged code can work, but this is the only thing that can be used to get the benefit of the interaction. For all interaction strategies, when the operation process is routed between local code and managed code, it is mandatory to provide some marshalling signals. At the same time, the interaction policy forces the developer to manually declare all the invocation parameters (in this case, you do not know the data type of the parameter, many times you can only pass all parameters in Int32 way, such as file handle, string pointer, etc. almost all parameters, There is only one int32, which is the IntPtr type, which, of course, is considered to be on a 32-bit machine. )。 Finally, the CLR cannot complete optimizations for data delivery on the boundaries of managed code and local code. Ignoring the benefits of using local code or COM objects, there's nothing better than that. I am strongly opposed to this principle. C++,com at the moment, there is definitely a survival advantage, and I think we should take full advantage of them and not ignore them. But the fact is that interaction does not always work, and many times we add new functionality to existing applications, improve and update existing tools, or, in other places, complete a new managed application to interact with the old application. The use of some interaction in practical applications will only slow down the replacement of the old system. So it's important to have a clear idea of what's going on between different interactive strategies. These costs are spent at the same time in development planning and run-time performance. In some cases, the final option is to rewrite the old code. There are times when you need to choose the right interaction strategy.

Before I discuss this interactive strategy that works for you, I need to spend some time talking about abandoning (just throw it out) strategy. The fifth chapter, working with the. NET Framework, shows you some. NET has already created for you the class and the technology, you may use directly or derives. For you you think a lot, you can identify some of the classes and you some code algorithms, and all in C # rewrite. The remaining code can be. NET Framework to replace the possible functional derivation that already exists in the This doesn't always work anywhere, at any time, but it's really a carefully considered migration strategy. The "Throw it Out" strategy is recommended throughout chapter 5th. This principle is focused on interaction, and it is indeed a painful thing.

Next, let's assume you've decided that rewriting all the code is not practical. Some different strategies require you to start with. NET to access the local code. You need to understand the inefficiencies in the overhead of passing data between local code and managed code boundaries. There are three overhead when using interaction. The first is Data cluster processing, which occurs when data is passed between the managed heap and the local code heap. The second is the overhead of a large amount of data throughput when managed and unmanaged code interacts. You and your users will have to bear these costs. The third cost is your own: you have to add a lot of work to the interaction in this mixed development environment. This is also the worst one, so your design should decide to minimize such overhead.

Let's start talking about the performance overhead of interaction and how to minimize those costs. Data clustering is one of the biggest factors, like network services or remote operations, where you need to use the cumbersome (chunky) APIs as much as possible rather than the small (chatty) API (data clustering means that you don't have the means to interact with local code in real time, and there's a delay. This delay is done using data to heap together, so that you should interact with the local code as little as possible, and select some APIs that can handle more data at once. You can interact with unmanaged code in a different way. You can rewrite existing unmanaged code to create a cumbersome API that is better suited to interacting APIs. A common COM application is to declare many attributes so that the customer can set and modify the state or behavior within the COM object. Each time the settings attribute is clustered, the data will have to cross the boundary. (And every time it crosses the interactive boundary, there is thunks.) This is very inefficient, and unfortunately, COM objects or unmanaged libraries may not be under your control. When this happens, you need to do more difficult work. At this point, you can create a lightweight C + + library that exposes types of functionality by using the Chunkier API you need. This will increase your development time (that is, the third cost).

When you encapsulate a COM object, make sure that the data type you have modified already provides the best data clustering strategy between the local code and the managed code. Some types can be clustered better than other types, trying to limit the types of data that are used to pass between local and managed code, using blittable data as much as possible. Blittable refers to types that are used by both managed code and local code. Data content can be copied directly without the internal structure of the object. In some cases, unmanaged code might use code from managed code. The blittable types are listed below:

System.Byte
System.SByte
System.Int16
System.UInt16
System.Int32
System.UInt32
System.Int64
System.UInt64
System.UIntPtr

In addition, a one-dimensional array of any blittable type is also a blittable type. Finally, any format containing the blittable type is also a blittable type. A formatted type can be a structure that explicitly defines the data hierarchy with StructLayoutAttribute,

[ StructLayout( LayoutKind.Sequential ) ]
public struct Point3D
{
　public int X;
　public int Y;
　public int Z;
}