tags:

views:

458

answers:

4

I've recently been wrestling with an algorithm which was badly implemented (i.e. the developer was pulled off onto another project and failed to adequately document what he'd done) in C#.

I've found an alternative (from numerical recipes) which works but is written in C++. So I'm thinking probably the safest way to get something working would be to wrap the C++ up in a DLL.

Bearing in mind that I'm still a bit green when it comes to C# and have never tried making a DLL from scratch, does this sound like a reasonable approach (and if so, has anyone tried this / got any advice)? Or should I go the whole hog and try and port the C++ routine into C#?

Edit - I'm not looking for anyone to make the decision for me, but if anyone has any exprience of either route I'd be interested to hear their opinions and any nasty pitfalls that should be avoided. For example, how nasty is passing in lists of data from C# to a C++ STL vector?

+1  A: 

It depends what your goals are.

If it's to have a working application I'd weigh-up the costs and benefits of both approaches and go with the most cost effective.

If it's to improve your C# then by all means rewrite the C.

ChrisF
...and I wouldn't expect you too :-) I was asking the question to try and guage anyone else's experiences of either of the options. Maybe I should rephrase that a little.
Jon Cage
Line about making decision removed.
ChrisF
+1  A: 

...Or you could download the already implemented code in C# from here.

Mitch Wheat
I'd seen that version, but it seems to be a significantly different implementation (inputs/outputs are wildly different to my reference model)... that may well be my interpretation of the code though.
Jon Cage
would the downvoter please leave a comment. Thanks
Mitch Wheat
I already had - that implementation looks too different to my reference for a reasonable comparison (i.e. veriyfing that my code works would be much harder). It's not a bad answer, just not so relevent for the solution I'm looking for.
Jon Cage
@Jon Cage : That implementation seems to be used in quite a few apps.
Mitch Wheat
+2  A: 

If the C# version Mitch references isn't of a suitable licence for your purposes, You could use a managed C++ wrapper, that could reuse, and wrap the C code you have, but still be visible to your managed applications as a native .Net assembly. I've used this approach in the past for using the C API of a library that didn't have its own native .Net API, and found it relatively painless marshalling data between the two.

Rowland Shaw
That sounds encouraging. Do you have any links that could help me get into this? O'Reilly have a book which sounds like it might help ( http://www.ondotnet.com/pub/a/dotnet/2004/03/29/mcpp_part3.html )
Jon Cage
I'm afraid I don't have any links -- that link you've found looks quite good in itself, and of course you can ask on StackOverflow if you need to address any specific stumbling blocks
Rowland Shaw
+3  A: 

I tried linking to c-dll's from c# code with quite good results, even though I had some problems sending data between the environments. Otherwise the procedure is quite straight forward. The more data you send back and forth (both amount and frequency) the slower your program will run, but you have probably already figured this out on your own.

The main drawback was maintaining the c#-c glue code (interface code) each time something changed or someone found a bug.

Here is a bit of code to get you started:

using System.Runtime.InteropServices;
    class myDllCaller {

       //call to function in the dll returning an int
      [DllImport("MyFavorite.dll")]
      private static extern int dllFunction(//list of parameters to function);

    public static void Main() {
    int rerult = dllFunction();

    }
}
AnnaR
Thanks for the code snippet, will be useful ;)
Charlie Somerville
Excellent - I'll give this a shot.
Jon Cage