C#/C++ pInvoke tips

a 夏天 提交于 2020-01-01 06:06:08

问题


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


回答1:


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.




回答2:


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.




回答3:


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




回答4:


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.



来源:https://stackoverflow.com/questions/876553/c-c-pinvoke-tips

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!