[Mono-dev] C++, COM interop

[BGB]

----- Original Message ----- 
From: "QbProg" <tholag at gmail.com>
To: <mono-devel-list at lists.ximian.com>
Sent: Wednesday, January 21, 2009 7:22 AM
Subject: [Mono-dev] C++, COM interop


>
> Hello Mono users and developers!
>
> I have a native C++ class library , a COM wrapper written in ATL and a 
> .NET
> wrapper written in C++/CLI.
> Now, I'm thinking how it would be possible to write a mono wrapper that 
> runs
> mainly in LINUX.
> Basically I see two suggested ways:
> - Write a flatten "C" version on the library and use P/Invoke
> - Use SWIG to do such a thing
>
> I don't like neither of these, since the wrapper has many functions and
> classes.
> I see a better in using a sort of COM / XPCOM interfaces.
>
> I have no problems in making the wrapper based on interfaces (like I did 
> for
> the COM one). The only thing that I can not use are class factories since
> COM is not available in Windows. Hoever , I've got no problem in 
> eventually
> writing a custom factory for required COM Classes.
>
> I see that there is a main difference between COM and XPCOM interop. (?)
> In com you can write
> CClass c = new cClass ()
>
> and the COM layer will call the relative class factory. In XPCOm you have 
> to
> call manually a function to create the class.
>
> The question is : is there a way to redirect the "new" for a COM class (in
> linux) so I can directly call a custom class factory function (this time
> "internal") ?
> I.e.
> COMClass C = new COMClass;
>
> i.e. instead of calling CoCreateObject should call an internal function
> CreateCOMClass ?
>
> I don't know if I made it clear...
>
> I'll continue trying, and I'll share my experience, so maybe users can 
> find
> an additional way to wrap C++ classes.
>


I am not sure if others would agree here, but personally I feel a much 
"better" approach (or, at least it avoids COM...) would be to write an 
autowrapper tool to automatically generate either a plain C-based API, or a 
JNI-based API, and another tool to emit the code needed to import all of 
this back into .NET (via P/Invoke) or similar...

in such a tool, each class is converted to a raw/"incomplete" pointer, and 
each method is converted into a function with a mangled name accepting the 
class as the first argument. the whole mass would be C++, but all functions 
are declared with "extern C".

a pair tool would generate all the interface code in C++/CLI or C# or 
similar (treating the C++ classes as unmanaged pointers and calling the 
wrapper functions via P/Invoke...).


of course, this would be fairly similar to what SWIG does, assuming SWIG 
does not do this already (I have not looked into SWIG that much 
personally...).

but, in any case, assuming the C++ headers are fairly "clean", the tool need 
not even fully understand C++ syntax to pull this off (AKA: a dumb tool 
representing a state machine and processing 1 line at a time, ignoring 
anything it doesn't recognize).


although not for C++ (mostly I use C for various reasons, mainly that it is 
much easier to "tool" than C++ ...), a few of the major tools in my codebase 
work similar to this (mostly because I am too lazy to bother with keeping 
headers up to date, I find it more convinient to just write the code and 
make use of a special tool to write many of the headers for me...).

I had also decided long ago I would not make use of a language which I could 
not within reasonable effort implement automated tools for, and so I stick 
mostly to C. OTOH many people use C++ for most things, and end up with 
codebases which are not easily ammended to the use of automated tools, is 
not exactly standardized at the level of generated machine code, object 
layout, ... (2 independent C++ compilers tending to produce code which will 
not link, ...).


(actually, if such a tool were implemented, would it be reasonable to 
package it with Mono?...).

or, maybe this already exists and I missed it (I don't have this problem, so 
I didn't look...).

actually, this kind of a thing is a major reason why I use C-based APIs for 
all my libs (even if internally they use C++). as such, any C++ based API is 
then implemented as a wrapper over the C-based one (a library can be written 
in C++, and there is an external C++ - based API as well, but they do not 
directly communicate as such, which also helps promote abstraction between 
the frontend and the library internals...).


or such...


> Thank you.
> QbProg
> -- 
> View this message in context: 
> http://www.nabble.com/C%2B%2B%2C-COM-interop-tp21539294p21539294.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>