views:

673

answers:

4

Whats the best way to go about modifying a C++ program to be used with pInvoke from C#.NET CF?

I have a large C++ codebase which makes extensive use of STL. Namely iterators, container classes, and standard strings.

On top of this many lightweight classes are passed around by value.

I want to build a C# gui ontop of this codebase for windows mobile touch devices.

Is it worth it?

I have managed to get some examples working using pInvoke to call C++ code from C#.NET, but writing wrappers for every access point and for all the STL return types seems very daunting and ugly. Is there another way or am I somewhat stuffed?

BTW. Managed C++ is not an option becuase its not supported in any form by .NET CF.

--edit: I have one specific question in regards to pinvoke.

Suppose you had a function returning a C++ string by value

std::string foo () {
   return std::string ("Hi");
}

I understand that its not possible to call this function from C# using pinvoke because there is no way to marshall the STL string, but my problem is that I cannot even write a wrapper without allocating a new array becuase the std::string returned is not on the heap.

char* foo2 () {
   return foo().c_str(); //Very bad
   //the returned pointer is released when the std::string falls out of scope.
   //and will be invalid before the caller is able to do anything with it.
}

So my problem is, how to wrap foo into a pInvoke suitable format without needing to re-allocate the whole string.

char* foo2 () {
   std::string f = foo();
   char* waste = new char[f.length()+1];
   strcpy (waste, f.c_str());
   return f;
}

The thought of doing the above for every point at which I need to return a std::string is enough to make me give up trying to use C#.

A: 

maybe you should write a com wrapper and then use .net tool that will automatically create c# assembly for you?

Trickster
I don't think there is a COM subsystem in WindowsMobile...
JasonRShaver
COM is there in windows mobile
1800 INFORMATION
It's there, but COM interop in the CF is *not* easy at all.
ctacke
+1  A: 

What you want to do is not easy at all. If you really wanted to do it, your best bet is to create some clean, C interfaces that wrap all of the C++ and STL stuff and pass around structures that can pass from .net to C nicely. Depending on how big of a codebase you have, it can be a very difficult task.

Sorry.

JasonRShaver
Thanks for the advice, I assumed this was the case but wanted to be sure before going down that road.
Akusete
+2  A: 

I would personally say it's worth it, but I agree with the other post that it's not easy.

Possible approaches may be:

  1. C interface around the C++ and exposed as a DLL.
  2. COM objects (altho WM does not support COM servers so you are forced to use in-proc servers, basically a DLL COM implementation). This would give you a more OO interface.
  3. Background process exposing some sort of API. You could go down the "CE Services" modal or come up with your own API.

All are possible and have there pros and cons. Whatever you do, you can't use STL types in the interface. You have reduced to simple basic types that are easy to marshal between the processes. Since your talking about C#, then COM may be go as you can expose OO interface.

I would recommend trying to keep the interface between the two as simple as possible.

Shane Powell
Thanks for the tips, although I'm not sure what option 3 means. I agree that my interface was too broad and I should make the bridge between C# and C++ as small as possible. Currently even iterator references are returned which require a pinvoke call every time they increment or dereference themselves... eek.
Akusete
Option 3: You create a application (exe) that runs in the background (it can either run all the time or started and stopped by the gui front end) and communicates with your front-end (GUI) application using some sort of API you make up like using shared memory or message queues or anything you like. Sort like Win32 services. Your background application would normally site in some sort of event loop receiving commands and processing them.
Shane Powell
A: 

doesnt SWIG create a C-style wrapper for C++ for you? Like handing all the non-basics of complex c++ ? Correct me if i'm wrong because I'm in a similar situation, I want to wrap a very large and complex C++ api exposed in a dll..i need to avoid mangling and the non basic data types by writing a C-style wrapper to expose all the stuff before Pinvoking that and it is infeasible without automated tools given the size of the api and the complexity of the types and prototypes.

Palace