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

[Alan McGovern]

Hey,

Join us in the #monosoc channel on irc
(http://www.mono-project.com/IRC). Also, I believe the deadline for
proposals is tomorrow so you should probably submit a proposal asap
which can be updated/modified later on as required. If you miss that
deadline, there's not a chance of the project being selected.

Alan.

On Thu, Apr 8, 2010 at 10:25 AM, Alex Corrado
<alexander.corrado at gmail.com> wrote:
> 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" 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 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/
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>