[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.sdk

.NET calling native c++ and threading

Mike

9/29/2003 7:00:00 PM

I'd like to call C++ from C#. I don't want to use COM becuase I want to be
able to call the C++ code from device-driver side fn's as well, and I need
to be able to target portable devices with the CF, so that leaves me with
PInvoke. Questions:
(1) Is there anything more than PInvoke available, so I don't need to write
wrappers to flatten the C++ object hierarchies into a bunch of extern "c"'s?
(For languages such as Python there are tools such as SWIG, Boost, PyInline,
CXX, Weave, etc., that help automate this process.)
(2) The C++ code creates several threads which it uses to do network i/o.
Will the CLR be okay with this? Is the message pump the best way to tell
managed code that a new event has occurred?

thanks,
mike
2 Answers

Kumar Gaurav Khanna

9/30/2003 5:06:00 AM

0

Hi!

Yes, there's another option than PInvoke: Managed C++. You could use MC++ to
create managed C++ wrapper classes around your existing unmanaged C++
classes. Your .NET application will call the methods against the managed C++
class which shall internally delegate calls to the unmanaged class. Infact,
this approach gives better interop, thats more efficient that PInvoke, with
lesser overhead.

Threads created by unmanaged code has got nothing to do with the CLR. So,
yes, CLR will be "okay" with it.

You could create an event handle and have the managed code wait on it.
Consider using WaitHandle class for the same.

Regards,
--------------------------------------------------
Kumar Gaurav Khanna
Microsoft MVP - .NET, MCSE Windows 2000/NT4, MCP+I
WinToolZone - Spelunking Microsoft Technologies
http://www.wintoo...
OpSupport - Spelunking Rotor
http://opsupport....

"Mike" <vimakefile@yahoo.com> wrote in message
news:%23qHT%23vrhDHA.1952@TK2MSFTNGP10.phx.gbl...
> I'd like to call C++ from C#. I don't want to use COM becuase I want to be
> able to call the C++ code from device-driver side fn's as well, and I need
> to be able to target portable devices with the CF, so that leaves me with
> PInvoke. Questions:
> (1) Is there anything more than PInvoke available, so I don't need to
write
> wrappers to flatten the C++ object hierarchies into a bunch of extern
"c"'s?
> (For languages such as Python there are tools such as SWIG, Boost,
PyInline,
> CXX, Weave, etc., that help automate this process.)
> (2) The C++ code creates several threads which it uses to do network i/o.
> Will the CLR be okay with this? Is the message pump the best way to tell
> managed code that a new event has occurred?
>
> thanks,
> mike
>
>

Mike

9/30/2003 3:33:00 PM

0


Thanks... I knew about MC++ but always thought it was such a strange "worst
of both worlds" approach -- but I guess the glass is really half-full when
it's needed for this type of application. I assume I should make an "empty"
managed subclass the UM code as my wrapper? What the difference between
writing a mangaged wrapper to my UM code, or just throwing the switch and
compiling the C++ in IL (in this case I have all the source), assuming that
I can access the few (socket) libs I want from the framework?

thanks

"Kumar Gaurav Khanna [.NET MVP]" <gaurav@wintoolzone.com> wrote in message
news:eu%23GnCxhDHA.2984@TK2MSFTNGP11.phx.gbl...
> Hi!
>
> Yes, there's another option than PInvoke: Managed C++. You could use MC++
to
> create managed C++ wrapper classes around your existing unmanaged C++
> classes. Your .NET application will call the methods against the managed
C++
> class which shall internally delegate calls to the unmanaged class.
Infact,
> this approach gives better interop, thats more efficient that PInvoke,
with
> lesser overhead.
>
> Threads created by unmanaged code has got nothing to do with the CLR. So,
> yes, CLR will be "okay" with it.
>
> You could create an event handle and have the managed code wait on it.
> Consider using WaitHandle class for the same.
>
> Regards,
> --------------------------------------------------