[Mono-dev] Summer of Code / C++ Interop

[Alex Corrado]

Dear Mr. de Icaza and the Mono Developer Community,

First, I would like to salute you for producing an excellent, open platform
for software development. Second, I would like to apologize for bothering
anyone who is not interested in a student's proposal to improve it. I
appreciate your time and any feedback you might give.

I am proposing to expand Mono's C++ interop support to enable the creation
of managed wrappers directly around native C++ objects. This would make C++
libraries callable directly from managed code without the need for wrapping
them in a flat C API, COM interface, or requiring the use of mixed binaries
(C++/CLI). In fact, this could also provide a way to implement the C++/CLI
language, including IJW, in a cross-platform manner.

The first place I read about calling C++ functions directly from managed
code was on Mono's "Interop with Native
Libraries<http://www.mono-project.com/Interop_with_Native_Libraries#Invoking_Unmanaged_Code>"
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<http://blogs.msdn.com/vcblog/archive/2008/12/08/inheriting-from-a-native-c-class-in-c.aspx>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<http://www.codesourcery.com/public/cxx-abi/abi.html>,
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 would include some details about myself, but I feel like this email is
already long enough. So if there is anything in particular you would like to
know, or any feedback you might have, please feel free to contact me. Thank
you very much for your time.

Sincerely,
Alexander Corrado
Undergraduate Student at the University of Oregon
alexander.corrado at gmail.com
http://code.google.com/p/cppinterop/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100408/715ee81d/attachment.html