[Mono-dev] Summer of Code / C++ Interop
andreas.faerber at web.de
Thu Apr 8 09:06:08 EDT 2010
Am 08.04.2010 um 11:25 schrieb Alex Corrado:
> I am proposing to expand Mono's C++ interop support to enable the
> creation of managed wrappers directly around native C++ objects.
> The first place I read about calling C++ functions directly from
> managed code was on Mono's "Interop with Native Libraries" page. It
> suggested setting the EntryPoint of the DllImport attribute to the C+
> + mangled function name to call that function directly through P/
> Invoke. However, it wasn't until I read this blog post by Jim
> Springfield that I realized that, not only could this be a viable
> technique, but that by messing with virtual tables, native C++
> classes could effectively be subclassed by managed code. This
> technique could allow for seamless managed wrappers around native C+
> + classes.
> Jim Springfield's example is tied completely to Microsoft's Visual C+
> + compiler, and this illustrates the largest problem with this
> approach: that C++ ABIs are different among different compilers and
> even between different versions of the same compiler. To help
> ameliorate this issue, I have taken the basic principles in
> Springfield's design and abstracted out any ABI-specific components
> into an abstract class. A different subclass of this CppAbi class
> can then be implemented to support each compiler's different name
> mangling schemes and other idiosyncrasies. At runtime, the correct
> CppAbi instance can be chosen when loading the C++ library depending
> on platform or other conditions. Reflection.Emit is then used to
> generate the P/Invoke code and implement trampolines to facilitate
> virtual method calls. Eventually I hope to support seamless
> exception handling and other features supported by C++/CLI on Windows.
> I realize this sounds very ambitious, but I've already implemented a
> proof-of-concept based on a simple C++ class, similar to the one Jim
> Springfield uses in his example. It is hosted on Google code at http://code.google.com/p/cppinterop/
> . Please note that this really is just a proof-of-concept-- I've
> only implemented the Itanium C++ ABI, and only in part. If you are
> using a recent version of GCC to compile C++, you should be able to
> compile the example and call it directly from managed code. I've
> only tested this on an Intel Mac running OS X 10.4.11.
I've recently investigated ways to p/invoke C++ code myself and
considered going the name-mangling way, so this sounds interesting!
Can't comment on whether it's suitable for GSoC though.
CSimpleClass.cs looks as if it was written manually. I see a problem
with changing C++ code there: To allow managed code to instantiate
such a class, your private struct needs to match exactly the size of
the native code. If however someone adds a private field in C++ but
does not update the interop code, it will fail. Would it be possible
to leave the memory allocation to C++ (the ABI document mentions "nw"
in the name-mangling section) and in C# just map the methods we
actually want to call?
For your proposed project, would you be focussing on the p/invoke ABI
infrastructure only? Any plans for SWIG-like autogeneration of the
(C#) proxy interfaces from C++ headers? And what about C++ interop
inside Mono's class libraries?
More information about the Mono-devel-list