C ++ wrap for use in C #

Question

Ok, basically there is a big C ++ project (Recast) that I want to wrap in order to use it in my C # project.

I have been trying to do this for a while, and this is what I still have. I use C ++ / CLI to port the classes that I need so that I can use them in C #.

However, there are a ton of structures and enumerations that I will also need in my C # project. So how to wrap them?

The main method I'm using right now is adding dllexport calls to native C ++ code, compiling into dll / lib, adding this library to my C ++ / CLI project and importing C ++ headers, and then compiling the CLI project in the dll finally adding this dll as a reference to my C # project. I appreciate any help.

Here is some code ... I need a controlled way to do this, since the C ++ project is so large.

//**Native unmanaged C++ code //**Recast.h enum rcTimerLabel { A, B, C }; extern "C" { class __declspec(dllexport) rcContext { public: inline rcContect(bool state); virtual ~rcContect() {} inline void resetLog() { if(m_logEnabled) doResetLog(); } protected: bool m_logEnabled; } struct rcConfig { int width; int height; } } // end of extern // **Managed CLI code // **MyWrappers.h #include "Recast.h" namespace Wrappers { public ref class MyWrapper { private: rcContect* _NativeClass; public: MyWrapper(bool state); ~MyWrapper(); void resetLog(); void enableLog(bool state) {_NativeClass->enableLog(state); } }; } //**MyWrapper.cpp #include "MyWrappers.h" namespace Wrappers { MyWrapper::MyWrapper(bool state) { _NativeClass = new rcContext(state); } MyWrapper::~MyWrapper() { delete _NativeClass; } void MyWrapper::resetLog() { _NativeClass->resetLog(); } } // **C# code // **Program.cs namespace recast_cs_test { public class Program { static void Main() { MyWrapper myWrapperTest = new MyWrapper(true); myWrapperTest.resetLog(); myWrapperTest.enableLog(true); } } } 

Answer 1

Typically, C / C ++ structures are used to communicate with native code, while you create CLI classes to communicate with .NET code. C structures are "dumb" because they can only store data. On the other hand, .NET programmers expect their data structures to be smart. For example:

If I change the "height" parameter in the structure, I know that the height of the object will not actually change until I pass this structure to the update function. However, in C #, the general idiom is that values ​​are represented as “Properties,” and updating a property will immediately change those changes.

That way, I can do things like: myshape.dimensions.height = 15 and just expect it to "work."

To some extent, the structures that you provide to the .NET developer (like classes) are actually APIs, with the behavior displayed on the properties and methods of these classes. While in C, structures are simply used as variables that are transferred from functions that do the work. In other words, .NET is usually an object-oriented paradigm, while C is not. And a lot of C ++ code is actually C with a few fantastic bits thrown for spice.

If you are writing a translation layer between C and .NET, most of your work is to create the objects that will make up your new API and to provide the translation of your basic functions. Structures in C code are not necessarily part of your new hierarchy of objects; they are part of API C.

edit to add:

Also consider

Alternatively, you can reconsider your choice of using C ++ / CLI and consider C # and p / invoke instead. For various reasons, I once wrote a wrapper for OpenSSL using C ++ / CLI, and although it was impressive how easy it was to create and how it worked, there were a few troubles. In particular, the bindings were tight, so every time the parent project (OpenSSL) updated its library, I had to recompile my shell to match. In addition, my shell is forever tied to a specific architecture (either 64-bit or 32-bit), which should also have been consistent with the build architecture of the base library. You are still having problems with architecture with p / invoke, but they are a little easier to handle. In addition, C ++ / CLI does not work well with introspection tools such as Reflector. And finally, the library you create is not portable for Mono. I did not think this would be a problem. But in the end, I had to start from scratch and run the whole project in C # again using p / invoke.

On the one hand, I am glad that I did the C ++ / CLI project, because I learned a lot about working with managed and unmanaged code and memory in one project. But, on the other hand, there was probably a lot of time that I could spend on other things.

Answer 2

I would look at creating a COM server using ATL . However, this will not be a simple port. You will have to create COM-compatible interfaces that display the functionality of the library you are trying to wrap. As a result, you will have more control capabilities and a fully supported COM Interop interface.

Answer 3

Perhaps one of them will help:

• http://blogs.microsoft.co.il/blogs/sasha/archive/2012/01/24/managed-unmanaged-interoperability-in-the-2010s-part-1-p-invoke-managed-to-unmanaged. aspx

• http://blogs.microsoft.co.il/blogs/sasha/archive/2012/01/28/managed-unmanaged-interoperability-in-the-2010s-part-2-p-invoke-unmanaged-to-managed. aspx

• http://blogs.microsoft.co.il/blogs/sasha/archive/2012/01/30/managed-unmanaged-interoperability-in-the-2010s-part-3-c-cli-and-other-options. aspx

Answer 4

If you are ready to use P / Invoke, SWIG software could help you: http://www.swig.org/