Mixing Native and Managed Types in C++
Wow, its turning into a busy month. I just haven’t had any time to blog despite having a number of interesting topics to cover. I’ll try to get a few of them written soon. Here’s a topic from one of my regular readers.
The CLR naturally supports mixing managed and native method calls allowing you to easily call native functions from managed functions (which are of course natively compiled before execution) and visa versa. This is all largely transparent in C++. What’s not as transparent is how to mix managed and native types. The reason is that there is a greater distinction between native and managed types compared with function calls. Beside obvious differences such as those introduced by different calling conventions and virtual invocation, function calls aren’t all that different. Types however require a bit more help from the programmer/compiler since native and managed types can have very different characteristics. This is very evident in C# as you often need to decorate native type definitions with all kinds of attributes to control memory layout and marshalling. Fortunately for the C++ programmer the compiler takes care of much of this when you define or include native type definitions such as those found in the various Windows header files, but the programmer is still responsible for telling the compiler just how those types are to be used.
Visual C++ provides many of the building blocks for mixing native and managed types but in some cases you need to write a little code to help it along. Fortunately C++/CLI is very capable. Let’s consider a few different scenarios.
Embed Simple Managed Type in Native Type
Since the CLR needs to keep track of every single instance of a managed type in a process, storing some kind of reference/pointer/handle to a managed object in a native type is not directly supported since instances of native types can be allocated in any region of memory and cast to all kinds of foreign data types that would be completely opaque to the CLR and its services. Instead you need to register such occurrences with the CLR so that it is aware of these “native” references to managed types. This is achieved with the use of the GCHandle type. Internally GCHandle manages a static table of (native) pointers that are used to lookup the objects in the managed heap. Of course using GCHandle directly from C++ can be quite tedious. It’s a CLS compliant value type which means native pointers are represented by IntPtr values. It also does not preserve static type information so static_casts are inevitable. Fortunately Visual C++ ships with the gcroot native template class that provides a strongly-typed interface over the GCHandle type.
#include <vcclr.h>
?
ref struct ManagedType
{
??? void HelloDotNet()
??? {
??????? Console::WriteLine("Hello .NET");
??? }
};
?
struct NativeType
{
??? ManagedType m1;????????? // Error!
???
??? ManagedType^ m2;???????? // Error!
???
??? gcroot<ManagedType^> m3; // OK
};
?
void main()
{
??? NativeType native;
??? native.m3 = gcnew ManagedType;
?
??? native.m3->HelloDotNet();
}
As you can see, gcroot provides a “smart” pointer for storing handles in native types. It may be smart but it does not provide automatic cleanup of resources. Specifically, the gcroot destructor makes no attempt to dispose of the managed object’s resources.
Embed Managed Resource in Native Type
Enter the auto_gcroot class. This native template class wraps a gcroot and provides transfer-of-ownership semantics for managed objects stored in native types. If you’re looking for a point of reference, think of the auto_ptr template class from the Standard C++ Library which does the same thing for native pointers. The auto_gcroot destructor takes care of “deleting” the handle which results in the object’s IDisposable::Dispose method (if any) being called.
#include <msclr\auto_gcroot.h>
?
ref struct ManagedType
{
??? void HelloDotNet()
??? {
??????? Console::WriteLine("Hello .NET");
??? }
?
??? ~ManagedType()
??? {
??????? Console::WriteLine("dtor");
??????? // Compiler implements Dispose pattern...
??? }
};
?
struct NativeType
{
??? msclr::auto_gcroot<ManagedType^> m3; // OK
};
?
void main()
{
??? NativeType native;
??? native.m3 = gcnew ManagedType;
?
??? native.m3->HelloDotNet();
}
The NativeType destructor (provided by the compiler) will automatically call the auto_gcroot destructor which will delete the managed object resulting in its destructor being called through its compiler generated Dispose method.
Embed Native Type in Managed Type
Now let’s turn things around. Let’s say we want to store a native type as a member of a managed type. The challenge is that the only native type the CLR really supports within managed types is a native pointer. C# programmers use IntPtr but that is only because IntPtr is the CLS compliant way of representing a native pointer and C# tries really hard to remain CLS compliant. The CLR fully supports storing native pointers without losing type information.
struct NativeType
{
};
?
ref struct ManagedType
{
??? NativeType n1; // Error!
??? NativeType* n2; // OK
};
That’s great except that now we have a resource management issue. Recall that C++ does not have the separation of memory and resource management evident in the CLR. The native object pointed to by the ManagedType member needs to be deleted. Here is one solution.
ref struct ManagedType
{
??? NativeType* n2; // OK
?
??? ~ManagedType()
??? {
??????? if (0 != n2)
??????? {
??????????? delete n2;
??????????? n2 = 0;
??????? }
??? }
};
Now the ManagedType has a Dispose implementation that will faithfully delete the native object. But this can become tedious and error prone very quickly. A better solution is to use some kind of “automatic” approach. Fortunately C++/CLI support by-value semantics for members so all we need is a managed auto-pointer template class. With such a class the ManagedType becomes really simple.
ref struct ManagedType
{
??? AutoPtr<NativeType> n2; // OK
};
ManagedType stores a pointer to a native object and its destructor automatically deletes the object. Woohoo!
The C++ compiler really takes care of a lot of boilerplate code. If you’re not sure just how much code the compiler is taking care of for you then?take a look at the compiled assembly in a disassembler.
Although Visual C++ does not provide a managed AutoPtr class, it is reasonably simple to write one. Here is a basic implementation.
template <typename T>
ref struct AutoPtr
{
??? AutoPtr() : m_ptr(0)
??? {
??????? // Do nothing
??? }
??? AutoPtr(T* ptr) : m_ptr(ptr)
??? {
??????? // Do nothing
??? }
??? AutoPtr(AutoPtr<T>% right) : m_ptr(right.Release())
??? {
??????? // Do nothing
??? }
??? ~AutoPtr()
??? {
??????? if (0 != m_ptr)
??????? {
??????????? delete m_ptr;
??????????? m_ptr = 0;
??????? }
??? }
??? T& operator*()
??? {
??????? return *m_ptr;
??? }
??? T* operator->()
??? {
??????? return m_ptr;
??? }
??? T* Get()
??? {
??????? return m_ptr;
??? }
??? T* Release()
??? {
??????? T* released = m_ptr;
??????? m_ptr = 0;
??????? return released;
??? }
??? void Reset()
??? {
??????? Reset(0);
??? }
??? void Reset(T* ptr)
??? {
??????? if (0 != m_ptr)
??????? {
??????????? delete m_ptr;
??????? }
??????? m_ptr = ptr;
??? }
private:
??? T* m_ptr;
};
In a future post I may?provide a few realistic examples of mixing native and managed code, but I hope this introduction has given you a few ideas on how to mix native and managed code and types effectively in C++.
來自: http://weblogs.asp.net/kennykerr/archive/2005/07/12/Mixing-Native-and-Managed-Types-in-C_2B002B00_.aspx