Are there any tools for porting c++ code to c# code?

views:

102

answers:

+2 Q:

Are there any tools for porting c++ code to c# code?

I have a couple c++ utilities that I would like to port over to dot net. I was wondering if there are tools for porting a c++ application to c#?

I imagine that any automated tool would make a mess of any code, so perhaps, I should also be asking if this is a good idea or not?

+2 A:

Sure, it is a lively market. Going from C++ to C# gives you something that might compile cleanly. Making it actually work takes a line-by-line, "oh gawd I'll shoot myself tomorow" effort. YMMV.

Hans Passant 2010-05-12 23:27:55

+1 A:

This should have been a comment. But I do not have enough credentials to post a comment. This is not exactly relevant to your question. I thought it will be useful for you.

C++ -> C#: What You Need to Know to Move from C++ to C#

Jujjuru 2010-05-13 00:08:30

+2 A:

Keyboard.
Mouse.
Monitor.
Coffee.
Regular expression search and replace.

Igor Zevaka 2010-05-13 00:10:29

+3 A:

The better question is why would you ever just port working code without gaining added value (ie new features)? The effort will almost cetainly be harder and take longer than you expect. Better, use the many interop capabilities of .Net to call your c++ code from C#. Focus on adding new features in C#, but don't waste your time porting working code.

Barry Wark 2010-05-13 00:14:32

Actually, if you are porting complex code, you DO NOT WANT to add new features as you are doing it. If you do so, you run the serious risk of not being to validate it. You sure can't compare it to the old system, as an example. If you intend to get value, you should port it as is, verify it is a correct port, and then take advantage of your new world. It is true that the perception of a migration is that it is terribly expensive, and you'd better get something "new" at the end. True, but if you don't survive the migration, it doesn't matter if you got something new in addition.

Ira Baxter 2010-07-31 20:26:22

Perhaps I expressed my idea poorly—I mean that you should not port just for porting sake. In the case of the CLR, you can keep your existing code and add any new features using C# rather than C++.

Barry Wark 2010-08-17 18:18:09

You must perform a cost/benefit analysis. With experience, you can easily ballpark it. There are many known examples of ports being worth the effort. For example, Hibernate -> NHibernate, and jUnit -> nUnit. These frameworks already had a wide audience, and served a need that wasn't yet fulfilled in the language they were ported to

Merlyn Morgan-Graham 2010-10-13 04:15:37

How about the C++/CLI compiler, which produces .NET assemblies from C++ code. Eventually you'll want to rework the entry points to accept .NET types (e.g. System::String instead of the classic char *), but you'll get to .NET a lot quicker by not using C#. There are also automated conversions between C++/CLI and C#, but only after the C++ code is .NETified (the aforementioned conversion to System::String, generic<typename T> System::Collections::Generic::List, etc.)

Ben Voigt 2010-05-13 00:36:53

I'm not down-voting this because I think it could apply, and is worth considering. But I am not up-voting this, because I think it could drastically complicate many scenarios, with little-to-no benefit. Leave it half-finished, and increase your job security =P

Merlyn Morgan-Graham 2010-10-13 04:22:13

@Merlyn: If you haven't used C++/CLI before, you might find it complicated. But the benefits of being able to port gradually and test each change in the context of a complete working system would be hard to overstate. Not as good as a complete unit test suite, but the next best thing.

Ben Voigt 2010-10-13 04:56:50

A gradual port means you're hamstrung by requiring the .NET framework, and by the continued presence of the unreadable mess that is most C++ code (probably foregoing some of its better features/libraries - I don't know to what extent, since I haven't used C++/CLI). You get the worst of both worlds. This isn't to say C++/CLI doesn't provide some cool features (I've glanced at Microsoft dev blogs that insist it is the best .NET language out there). But you won't be using most of them to start with, and any new technique is hard to integrate into an existing app. C++/CLI is a tough sell.

Merlyn Morgan-Graham 2010-10-13 15:44:44

And if your app is at all critical, and any level of complicated, you don't want to port until you have a full unit test suite. Writing one should be factored into the cost of the port...

Merlyn Morgan-Graham 2010-10-13 15:47:21

@Merlyn: And how, pray tell, do you use the same test suite for both the old and new code, if they're in incompatible languages? Or do you not validate the test suite by running it against the existing code before starting the porting process?

Ben Voigt 2010-10-13 18:03:56

@Ben: You don't :) You write the first one, validate your old code (because without a test suite, you have no idea where the bugs are), and write the 2nd one using TDD principals. It will be much easier to write the second test suite because you have an existing design and reference code. Again, if your app is critical or complicated, this cost will be well worth it. If your app isn't either of these, why would you bother to convert it/why would you want a tool that generates the port for you (ala the original question).

Merlyn Morgan-Graham 2010-10-14 02:04:48

Oh, and I weaken my standing a little. You can have no unit test suite, if you have an integration/black box test suite with good logical/code coverage. The point is that you need good tests.

Merlyn Morgan-Graham 2010-10-14 02:06:51

@Merlyn: I don't see how having two implementations of the same test suite actually assures anything. How do you verify that the second test suite does the same checks as the first one, if they're written on incompatible platforms? With C++/CLI, you could have a single test suite that tests both the original native code and the new .NET code.

Ben Voigt 2010-10-14 03:20:09

@Ben Voigt: "I don't see how having two implementations ... actually assures anything": It assures that you know how the system is supposed to act in the old version, and assures that it still acts that way in the new version. If you port the app blindly, then you can only make assumptions about how it is supposed to act. "How do you verify that the second test suite does the same checks as the first one": You port it the same way you port any software - not line-for-line mechanically. You'll have to remove/add cases, because the app won't be a 100% copy, either. E.g. manual dealloc vs. GC

Merlyn Morgan-Graham 2010-10-14 05:31:55

@Merlyn: You've just made my point. If the test suite gets ported "the same way you port any software", then it will end up with the same errors you would have had if you just ported the main code. The only way to assure that the code acts the same way after porting is to run the *same* test suite before, during, and after porting. And if your app is at all critical, you're not going to remove deallocation and just let the GC take care of it, because that leads to non-determinism. You're going to want deterministic cleanup in all the same places, and C++/CLI makes that easier too.

Ben Voigt 2010-10-14 14:11:56

@Ben Voigt: I think one problem is that we're both generalizing too much, here. For example, is this an ATL or MFC app? If so, how do you use C++/CLI to do a slow port? And if the original app used simple reference counting or RAII for dellocation, of course you'd want to simply remove deallocation. In other cases, such as pooled resources, of course you wouldn't.

Merlyn Morgan-Graham 2010-10-14 22:38:37

@Ben Voigt: I don't think we're seeing eye-to-eye on the duplicated test suite concept, so I guess I'll give up on it.

Merlyn Morgan-Graham 2010-10-14 22:56:57

@Merlyn: You're looking for problems where none exist. You'd just compile that MFC app with /clr, and then slowly replace it with .NET components, one piece at a time. For example there's [CWinFormsControl](http://msdn.microsoft.com/en-us/library/8z4d86s2.aspx) which lets you put WinForms controls inside an MFC window or dialog. So you really can have a working app at every milestone of the porting process. Resource pools aren't the only thing that need deterministic destruction, so do locks, file access, etc.

Ben Voigt 2010-10-14 23:00:05

My company, Semantic Designs has a tool that convert from C++ to C#. It handles the conversion core language constructs from C++ (data/class declarations, executable statements) to C#. The translation tool is based on the DMS Software Reengineering Toolkit.

It needs customization to handle translating exotic constructs (COM calls, your custom APIs, ...) to C#. Any tool you might find will need such customization; no off-the-shelf tool can practically address your complete set of specific circumstances.

Ira Baxter 2010-10-13 03:58:51

ansaurus

tags:

views:

answers:

Are there any tools for porting c++ code to c# code?

related questions