Passing data from a C process to a C++ process

Question

This is my first time posting a question here, I usually find answers in the archive but I'm stumped this time.

I'm grabbing data off of a joystick using some code from the vendor that uses Windows Driver Kit. The data is in the form of an array with 6 elements (it's a 6 degree of freedom mouse).

I had already written the code that needs to grab the data and it is in C++...it uses the standard library a lot with vectors and what not. It seems that using the standard library with WDK is a big head ache that I spent a couple days trying to get to work but failed. My next idea was to use boost::interprocess but this to is difficult to use with WDK for the same reasons.

I'm wondering if there is a way to share memory between a C process and C++ process. I would like to write the array to memory using a C program and read it in from a C++ program. It needs to happen very fast and there should be a way to make sure I don't read it in the middle of a write (mutex?).

Any ideas or suggestions are welcome.

EDIT I made a DLL instead, now I just have a DLL that has a getValues() function that I can call from my C++ project. I had to use the pimpl idiom to hide the c stuff though. Thanks for the help guys!!

Mcdermott

The usual solution would be to make a DLL that exports a function to get the data from the device. – Wizardry

Ah, thanks for your input (and so fast :)). I've never made a DLL but I guess there is a time for everything. I'll start researching. Thanks. – Mcdermott

One tip then: Don't do memory allocation across the DLL boundary. The executable can allocate a buffer for the DLL to fill in. Or the DLL can allocate a buffer, pass a pointer to it to the executable, and the executable can return it to the DLL when it's done so the DLL can free it. But don't allocate on one side and free in the other. – Wizardry

Yeah - it's easiest to pass in a *buffer and have the driver fill it in upon change and signal. – Rhinoceros

Answer 1

Perhaps I missed something, but it looks like you created a process to retrieve the joystick data. To save yourself some trouble, replace that process with the C DLL suggested in the comments. Your main C++ application can then simply call a function within that DLL to retrieve the joystick data without even worrying about locks or inter-process communication.

Of course, if you do need two processes, you'll need to use shared memory in the DLL and process-level locks. Shared memory is needed because DLLs are loaded separately into each process's virtual space; nothing is shared, hence the need for shared-memory.

Operational

I think the DLL idea could work...I'm trying it right now. After thinking about it a little, I really only need to be able to call a function from the DLL to grab data when ever I need. I don't really need shared memory. But even after I made the DLL I'm running into the same problem I had before...the DLL needs WDK's version of the standard library, and that means I can't use the regular standard library (<vector> and <iostream>. It happens since in my DLL I have to include hidsdi.h using extern "C"{} – Mcdermott

Correct. The DLL should be written in C and make life easy interfacing with the WDK. Transferring data between this DLL and your C++ app should not be using C++ structures, but a simple C-style array. You can then convert the results to whatever C++ friendly structure you want. – Operational

Thanks, I think I'm on the right track. My problem is that when I link to my DLL, I get a compiler error saying "cannot open include file : 'hidsdi.h'. Which is a header file that the DLL is including. I would have thought that my C++ project didn't care what the DLL needed. Is that wrong? – Mcdermott

You should probably create 2 header files. One containing "exports", which will be included by your C++ project. Another used only by the DLL project. The second will contain your inclusion of DLL-dependent includes. – Operational

Ouch, I feel like a dope. I wrote the whole dll in one .c file (no header). I know I know its bad. Thanks loan. – Mcdermott