Hash: SHA1

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 attention.

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.NET<http://VB.NET>and C# will both compile into the same MSIL code
or something?

[   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 ]
Version: GnuPG v1.4.1 (GNU/Linux)


vos-d mailing list

Reply via email to