views:

126

answers:

2

I have existing C++ lib containing many different classes working together. Some example usage should include something like passing an instance of one class to constructor/method of another class.

I am planning to provide a C# binding for these C++ classes using C++/CLI therefore I don't have to port the whole C++ code.

I can already do this in "Facade" way by creating another class which hides all the classes used in existing C++ code from the user. However, what I want is to provide the same classes with same method signatures to the user.

Is there any guideline or recommendation for this?

ps. I have looked at some of the existing opensource C# to C++ bindings projects. But they seem to used many different ways of doing this, and I don't really understand it.

+4  A: 

A lot of this is going to depend on the factoring of your classes.

In the work that I do, I try to treat the C++ classes I model as hidden implementation details that I wrap into appropriate C++/CLI classes. For the most part, I can get away with that by having managed interfaces that are NOT particularly granular. When your implementation involves directly implementing every detail of the underlying C++ code, then you'll end up with a very "chatty" interface that will involve a fair amount of cost in managed/unmanaged transitions.

In particular, if your unmanaged C++ classes use stl, especially stl collection types, you will likely find yourself in for an unpleasant surprise when you discover that every iteration through your stl collections involves several managed/unmanaged transitions. I had an image decoder that used stl heavily and it ran like a dog because of that. The obvious fix to put #pragmas around the code that accessed stl types didn't help. What I found that did work was to hide all of that in a handle-based C interface that hid all the C++-isms behind an iron curtain. No stl exposed anywhere meant that it was allowed to exist as unmanaged code.

I think your biggest issue is going to be in how you handle collections (if you use any) as the C++ collection philosophy and the .NET collection philosophy don't match up well. I suspect that you will spend a lot of time mapping .NET collections of adapted classes to your C++ collections of classes/types.

EDIT Here's a blog article I wrote about this issue some time ago. It uses the managed C++ dialect, not C++/CLI, but the issue is the same.

plinth
+1 - STL bit me in the bum too.
Simon
For the STL issue, isn't that pretty much what STL.NET tries to solve? (http://msdn.microsoft.com/en-us/library/ms379600%28VS.80%29.aspx)
jalf
Not at all - STL.NET is a different container class built on the design of stl. In this example, there is an unknown C++ class library that, because it is unmanaged, can't use STL.NET at all. The task is still the same: map STL types to .NET types, and if your architecture doesn't account for managed/unmanaged transitions, you're creating a performance bottleneck.
plinth
@plinth Thanks! Luckily STL isn't involved much :)
m3rLinEz
+1  A: 

I once did a C++ binding with C# using only [DllImport] attribute. If you don'd have any of the STL issues out fried up here says, and your lib is simple enough (as a single DLL, for example), I guess it's the easiest way to bind C++ and C#.

Simple example on MSDN: http://msdn.microsoft.com/en-us/library/aa984739(VS.71).aspx

Machado