[Mono-list] Managed C++ assemblies and Mono

Jason Whittington jasonw@develop.com
Fri, 10 Jan 2003 13:30:29 -0700

> I would agree that for a native C interface (e.g., GTK+), that would
> better.  From what I have seen of P/Invoke, however, it seems
> for use with a C++ API due to all the static methods.  

There's really no other practical way to do interop. This is due to a
weakness in C++, not a weakness in .NET.  C++ was written with
source-code compatibility in mind, not binary compatibility.  As a
result, C++ compilers are free to handle virtual dispatch and name
mangling however they like, making binary interop infeasible. 

As for your desire that things be more OO in nature, get over it :).
P/Invoke is actually way nicer to work with than, say, JNI.  Similar

>  What it really
> comes down to is that I want to write a class in C# that implements an
> interface defined in unmanaged C++.  An instance of the C# class would
> passed through to unmanaged C++ code.  There are a lot of details
> involved with this, but the inherent object-oriented nature does not
> to lend itself well to the structure of P/Invoke-style code.

Easier to say than to actually do. For this to work the runtime and the
C++ compiler would have to agree on a tightly-specified binary interface
contract. This has been done before; it was called COM (XPCOM on
Linux)[1]. COM interop is even more complex than P/Invoke, especially
when you start passing interface references around instead of flat data
structures.  Lifetime management and managed/unmanaged interaction turns
into a horrible sticky quagmire. Check out Adam Nathan's book[2] or Sam
Gentile's website [3] for more discussion.


[1]See Chapter 1 of "Essential COM" "COM as a better C++"

[2] ".NET and COM: The Complete Interopability guide"

[3] http://radio.weblogs.com/0105852/