Wrapping C++ for use in C#
Asked Answered
E

3

8

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

I've been trying to do this for a while now, and this is what I have so far. I'm using C++/CLI to wrap the classes that I need so that I can use them in C#.

However, there are a ton of structs and enums that I will also need in my C# project. So how do I wrap these?

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

Here is some code..I need manageable way of doing 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);
      }
   }
}
Endomorphic answered 1/3, 2012 at 18:34 Comment(2)
You might want to update the links description (:Anagnos
This might help #19265Elvinelvina
P
4

As a rule, the C/C++ structs are used for communicating with the native code, while you create CLI classes for communicating with the .NET code. C structs are "dumb" in that they can only store data. .NET programmers, on the other hand, expect their data-structures to be "smart". For example:

If I change the "height" parameter in a struct, I know that the height of the object won't actually change until I pass that struct to an update function. However, in C#, the common idiom is that values are represented as Properties, and updating the property will immediately make those changes "live".

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

To a certain extent, the structures you expose to the .NET developer (as classes) actually ARE the API, with the behaviors being mapped to properties and methods on those classes. While in C, the structures are simply used as variables passed to and from the 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 fancy bits thrown in for spice.

If you're writing translation layer between C and .NET, then a big part of your job is to devise the objects that will make up your new API and provide the translation to your underlying functionality. The structs in the C code aren't necessarily part of your new object hierarchy; they're just part of the C API.

edit to add:

Also to Consider

Also, you may want to re-consider your choice to use C++/CLI and consider C# and p/invoke instead. For various reasons, I once wrote a wrapper for OpenSSL using C++/CLI, and while it was impressive how easy it was to build and how seamless it worked, there were a few annoyances. Specifically, the bindings were tight, so every time the the parent project (OpenSSL) revved their library, I had to re-compile my wrapper to match. Also, my wrapper was forever tied to a specific architecture (either 64-bit or 32-bit) which also had to match the build architecture of the underlying library. You still get architecture issues with p/invoke, but they're a bit easier to handle. Also, C++/CLI doesn't play well with introspection tools like Reflector. And finally, the library you build isn't portable to Mono. I didn't think that would end up being an issue. But in the end, I had to start over from scratch and re-do the entire project in C# using p/invoke instead.

On the one hand, I'm glad I did the C++/CLI project because I learned a lot about working with managed and unmanaged code and memory all in one project. But on the other hand, it sure was a lot of time I could have spent on other things.

Perinephrium answered 1/3, 2012 at 19:18 Comment(3)
With a large 3rd party C++ project like this, the task of deciphering what parts to wrap seems pretty overwhelming.Endomorphic
@erebel55: True, but you can do it incrementally. Wrap the functionality you need for what you're trying to do right now. And go from there.Perinephrium
Managed-Unmanaged Interoperability in the 2010s: Part 3, C++/CLI and Other Options is worth reading for when is c++/cli is more suited for interop instead of P/invoke.Boer
K
2

I would look at creating a COM server using ATL. It won't be a simple port, though. You'll have to create COM compatible interfaces that expose the functionality of the library you're trying to wrap. In the end, you will have more control and a fully supported COM Interop interface.

Kind answered 1/3, 2012 at 18:53 Comment(7)
I don't see the advantage of what you're suggesting over using p/invoke instead. Care to elaborate?Perinephrium
Sure, this approach gives you the ability to create a component that can be consumed by .NET, but does not involve any mixing of managed and unmanaged code. IDL provides the ability to define data structures and interfaces that are COM compatible and, therefore, .NET compatible. There are downsides: you'll have to run as a COM component, which may create installation headaches, and you have to completely re-create the interface of your component. The core benefit is that you are running in pure unmanaged code, so there are no complications. This is a Windows only solution, because of COM.Kind
Unless he's a glutton for punishment, I would strongly recommend against using ATL in particular and COM in general. The former in particular is almost certainly going to cause far more problems than it's worth.Necrophobia
ATL does have it's weak points; I would say the big one is that it hides a lot of code and can be confusing, especially if you have no experience with C++ templates or COM. That said, I've found it to be a reliable framework and vastly preferable to writing custom COM interfaces in C++.Kind
The problem with COM is that MSFT provided no high-level tools for C++ developers to use it. I did a lot of ATL work once-upon-a-time, and bled my fingers reading "ATL Internals", probably the de facto book on the subject. Yes, it does the job, but it's arcane to say the least (I'm being euphemestically kind), and extremely difficult for most programmers to get their heads around. Most C++ developers are already challenged enough as it is. If program stability and maintenance costs mean anything, most organizations should avoid it like the plague.Necrophobia
ATL isn't that bad at all. I found writing new COM components using it was quite simple. Of course, your complaints about the complexity should really be directed at COM itself. ATL is a fine wrapper around it though. Use the new project wizards and you don't even have to think too hard about it.Eberhard
IMHO, most programmers don't have a clear understanding of either COM or ATL even when they think they do. That's not directed at you personally (I don't know you), but it is based on a lot of experience reviewing other people's code (and testing prospective developers during interviews). You'll frequently find egregious examples that back up my claim. You may be the exception rather than the rule, but the op will likely find that's not normally the case.Necrophobia
S
2

If you are prepared to use P/Invoke, the SWIG software could maybe help you out: http://www.swig.org/

Stomatic answered 1/3, 2012 at 19:26 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.