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

[Jason Whittington]

> I would agree that for a native C interface (e.g., GTK+), that would
be
> better.  From what I have seen of P/Invoke, however, it seems
undesirable
> 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
issues.

>  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
be
> passed through to unmanaged C++ code.  There are a lot of details
> involved with this, but the inherent object-oriented nature does not
seem
> 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.

Jason

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

[2] ".NET and COM: The Complete Interopability guide"
http://www.amazon.com/exec/obidos/tg/detail/-/0672321432/qid=1042230082/
sr=8-5/ref=sr_8_5/104-6049141-7111136?v=glance&s=books&n=507846

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