"Jon Slaughter" <Jo***********@Hotmail.comwrote in message
news:A4*******************@newssvr29.news.prodigy. net...
How difficult is it for one to integrate unmanaged C++ into C#? I know for
functions one can use DLLimport but how does one go about doing it for
classes? Do I have to completely reimplement the classes in managed C++ as
a wrapper to the unmanaged C++ classes or is there an easier way?
C++ classes cannot be used directly from C#, only pure C functions can be
called through the PInvoke layer.
The only way you can create instances of unmanaged C++ is by wrapping these
classes by a managed class that delegates the operations on the unmanaged
class.
Essentially what I have done is written a C++ kernel mode driver and I
want to use it from my C# program. Because it requires some setup outside
the kernel(because it has to pass buffers back and forth and extract the
information out of the buffers) I'd rather keep the that specific code
unmanaged because its probably slightly faster.
Not necessarely, keep in mind that you are adding a layer and as such you
are extending the path to the final code.
..
But I don't want to have a huge number of dll imports and write a C#
wrapper class over each of the imports because it seems a little
excessive. (Not only does the driver internally use a similar class but
I'd essentially be implementing the same class 3 times... one in the
driver, which is actually slightly different but pretty much with same
interface, one in unmanaged C++ to interface with the driver, and some
type of managed wrapper.)
Is there a better way? Can I just mix unmanaged and managed C++ in the
same project to do all the work and not have to end up with a C# wrapper?
Yep, you can have the wrapper and the native code in one project, even in
the same assembly. C++/CLI can mix native and managed code in a single DLL.
Basically I think I can get away with just using unsafe code to work with
the buffers. I'm mainly worried about the performance hit associated with
doing this. From my initial tests C# is anywhere from 2-5 times slower at
calling kernel mode drivers than unmanaged C++(not sure if I can get any
speed up by indirectly referencing unamanged C++ though so I might take
that hit no matter what if I plan on using C#). Of course I don't want to
end up with having to change 3 classes every time I make a simple change
either.
2-5 times? How did you compile the CS module, how did you declare the
PInvoke signature (DllImport), what function are you actually calling, what
are you measuring and how did you measure this?
The first time you call into unmanaged from managed you'll incur a serious
call overhead, this is because the CLR has to synthesize and JIT a
(marshaling) thunk, but once the thunk is created the overhead is very low,
all depends on the argument types, the number of arguments and the security
attribute set on the invoked function.
For instance, calling a function that takes no or only blittable type
arguments and which has the SuppressUnmanagedCodeSecurity attribute set [1],
the overhead is only 4 instructions. This is the minimal overhead taken to
signal the GC that the thread has transitioned into unmanaged or returned
from unmanaged.
Functions that take arrays or structures of blit-able types only, take an
overhead of ~50 instructions, while functions that take string arguments
[3], incur the highest overhead 50-xxx instructions depending on the type
unmanaged char (wide char or MBCS), the reason for this is that the
marshaler needs to convert the managed String representation into the
unmanaged char or wchar_t representation.
[1] 4 instructions overhead
[DllImport("lib.dll"), SuppressUnmanagedCodeSecurity] extern static int
F(int i);
[2] ~50 instructions overhead
[DllImport("lib.dll"), SuppressUnmanagedCodeSecurity] extern static void
F(int[] ia);
[3] ~55instructions overhead
[DllImport("lib.dll"), SuppressUnmanagedCodeSecurity] extern static int
FS([MarshalAs(UnmanagedType.LPWStr)] string s);
extern "C" __declspec(dllexport) int __stdcall FS(wchar_t *s){....}
a minimum of several hundred instruction depending on the string length.
[DllImport("lib.dll"), SuppressUnmanagedCodeSecurity] extern static int
FS(string s);
extern "C" __declspec(dllexport) int __stdcall FS(char *s){....}
The managed/unmanaged transition is low when compared to a kernel transition
(+ 4000 instruction), add to that that you will probably execute several
thousands instruction in the driver, and it becomes apparent that the
managed/unmanaged overhead becomes negligible. After all, this is the
overhead the you'll take when using the IO, Socket etc... classes from
managed code. Performing disk IO from managed code is not measurable slower
than from unmanaged code.
Willy.
