[Mono-dev] C++, COM interop
cr88192 at hotmail.com
Tue Jan 20 19:07:14 EST 2009
----- 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
> wrapper written in C++/CLI.
> Now, I'm thinking how it would be possible to write a mono wrapper that
> 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
> 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
> 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
> 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
> 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") ?
> 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
> 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
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...).
> Thank you.
> View this message in context:
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list