-BEGIN PGP SIGNED MESSAGE-
At work we have a large application that incorporates Managed and
Unmanaged C++, C# and several COM objects. .Net/CLR does a pretty good
job of tying it all together without too much fuss (except for the COM
objects, which are ugly and we're trying to get rid of).
For C++, it's easy for managed code to call unmanaged code, and I think
it's at least possible for unmananged code to call managed code. You just
compile the unmanaged project as /clr, and your managed code can #include
the headers and use the DLL just like normal. I presume it figures out
the P/Invoke stuff for you.
Calling unmanaged C code from C# is harder, because you have to explicitly
declare each function in your C# code. Creating C++ objects and calling
C++ methods from C# with P/Invoke is probably not possible.
So I expect it would be pretty easy to integrate VOS into a managed C++
project. To integrate VOS into an arbitrary .Net project, a set of API
wrappers would need to be written (or possibly generated by SWIG!) These
would convert std::string to System.String, manage the VOS reference
count, etc. This would be a lot more work.
For Unix, there's the Mono project. I don't know if they have any plans
for supporting Managed C++ (actually, I just did a google search, and it
looks like there is a nascent project to add it to GCC). Visual C++ 8 is
also going to have a totally new syntax for the managed extensions, so
it's probably not wise to put too much effort into it, anyway...
That said, I am interested in supporting VOS in .Net as this certainly is
where the Windows world is going. I don't know what the priority should
be, though. We should get at least one set of cross-language bindings
finished and integrated before worrying about others!
However, I'm just one developer, so unless someone is volunteering to work
on this, I think that I need to prioritize my time on fixing bugs and
adding features which will bring in some end users and attract more
On Fri, 2 Sep 2005, Neil Mosafi wrote:
Well finally something I feel qualified to comment on!
I'm not sure about C++ functions, but you can definitely call C functions
which are exposed in DLLs using P/Invoke in .NET. It's very simple - you
just create a bunch of .NET functions which match the C function signatures,
then you can use certain attributes for telling it which DLL the method is
in and how to marshal the managed memory to unmanaged memory. If you want a
nice API it's best to design something that behaves more like a .NET
component would (e.g using delegates and event handlers rather than
inheriting off the PropertyListener for notifications) which would take some
Anyway I can't possibly agree with Hugh's statement about C# being the same
as VB! It's much closer to C++/Java. Maybe he meant that
VB.NEThttp://VB.NETand C# will both compile into the same MSIL code
[ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
-END PGP SIGNATURE-
vos-d mailing list