views:

174

answers:

5
+2  Q: 

Porting C++ to C#

C++ and C# are quite simmilar programming languages, in my opinion. If a C++ code needs to be ported to platform where C# is the only supported platform, how much work will need to be done?

Should I get ready, that most of the C++ code will need to be rewritten to C#? Or, because of language simmilarities, should refactoring be quite easy and straightforward?

I am aware, that it will depend on the application itself, but I am asking in general.

+5  A: 

First thing first, this is porting and not refactoring. Also I think it's an extremely bad idea.

It is true that you could (with a lot of work) port C++ to unsafe C#, but saying that the syntax is very similar is a bit of a stretch. In fact, following the same line of reasoning you could port C++ to any other C derived language, and it would be equally painful.

Again, if you do it expect a shedload of rework. It's more than likely gonna take you more than re-coding it from scratch using the existing code as mere model, which is in my opinion a better and less messy option.

JohnIdol
+1, esp. for 'shedload'
Steve Townsend
Hi, JohnIdol, thanks for correction. Complete rewrite of the application is something I was affraid of. I know hat my question was subjective. Now I understand, that porting application from C++ to C# is not that trivial at all.
Bunkai.Satori
@Steve LOL - you a fan of shedloads? a polite alternative to shiiiitload ;)
JohnIdol
A: 

Porting C++ code to C# will not be that hard, assuming that all your dependent libraries have existing C# counterparts. Lack of dependencies is the most likely pitfall. The core concepts of your program, such as inheritance, heap, references, data structures, should be fairly easily translatable.

This is assuming that you don't invoke any specific low level behaviour such as custom memory management, because C# does not really support that kind of thing and you could have a serious problem there.

DeadMG
There are many C++ constructs (bit fields, (partial) template specialisation, non-type template parameters, ...) that have no equivalent in C#. "Will not be that hard" will only be true for a small subset of C++.
Richard
@Richard, true C# is really really bad at bit whacking.
kenny
+2  A: 

Just compile the C++ code with the /clr compiler option. That will translate the code to IL, it can execute on most any .NET enabled platform. There are very few C++ constructs that cannot be translated, it would have to use non-standard compiler extensions like __fastcall.

However, I suspect that you will find out that the platform requires verifiable code. Which is the common reason why a platform would restrict code to a .NET compliant language. I cannot guess at this since you didn't mention the execution environment. Native C++ translated to IL is not verifiable due to pointer manipulations. If that's the case then you are looking at a pretty drastic rewrite.

Hans Passant
Dar Hans, thank you for your answer. The target platform is MS XNA. At this moment, I develop application in C++, but later, I wish to port it to XNA.
Bunkai.Satori
If you actually intend to have it run on an XBox some day then you can't use native C++. No such restriction for a desktop. In which case my recommendation to build with /clr should work just fine.
Hans Passant
Hi Hans, my plan is running the ported app on Windows Phone 7.
Bunkai.Satori
You cannot use C++ on Windows Phone. Whatever existing C++ source you have is of little to no use.
Hans Passant
A: 

I'd be interested to know where C# is the "only supported platform".

The problem of rewriting in a new language can be whether you need to rewrite every single part of the code and cannot use any of the old code at all. Sometimes it is best, even when doing a rewrite, to make it more of a refactor: rewrite some parts of the code, move others. The existing code is known to work and can be tricky to reproduce. And it takes time. There needs to be a good reason to do a full rewrite.

.NET supports a version of C++, and Visual Studio also comes with Visual C++ to build standard C++, so consider whether or not you can make this a phased transformation, and whether or not you really have to rewrite the whole thing.

CashCow
Hello CashCow, as I've read Microsoft XNA framework does support only C# based applications. I would be happy, if I were wrong, but, I even searched "C++ XNA" on Google, but found nothing worth of mentioning.
Bunkai.Satori
+7  A: 

I have done a major port of a C++ application to C# recently. Overall I thought it was a pleasant experience. These are the steps that I took, they might or might not apply to your application.

  1. Get the "scaffolding" in place in C#, design your architecture. This is the time to get in major architecture changes from the existing application if you choose to do so.
  2. Get your tests in place. I can't over-emphasize this one. Since you are porting an existing application you should have a set of tests already in place that verify the correct behavior of your application. You can and should reuse these tests for your C# application. This is the one thing that gives you an edge when porting - you know (and have written) already many of the tests you want. Start porting your test project.
  3. Put in method stubs for your C# methods that reflect the existing C++ methods. Given the framework support in C# some methods might not be needed at all anymore, or are very simplified - this is the time to decide.
  4. Copy and paste. Yes I used copy and paste for most of the C++ code - all the flow statements basically can be reused if you are careful. Once pasted go through line by line, many things like use of pointers etc. must be rewritten to use a equivalent C# type.
  5. Once you have re-written a method in such a way, do the obvious re-factoring given the framework support / helper classes you might have been lacking in C++ but are readily available in C#. Also naming conventions for variables etc. can be changed here, should be straightforward given the built in support for this in VS 2010.
  6. Run your tests! Test early and often that the overall framework you have in place so far produces the exact same output as your C++ application which you can use as a reference. This is also the time to add missing tests.
  7. Refactor, Refactor, Refactor. Every application ages, and so did your C++ application most likely. Look closely at the underlying design and simplify and remove as much as possible. Verify at each step by running your tests.
BrokenGlass
Hi BrokenGlass, apparently, your advice seemst to be the most optimistic. I woudl like to avoid complete code rewritting if possible. Reusing as much as possible woudl be the preferred way. Thanks for the reply.
Bunkai.Satori
+1, very good advice
Thomas Levesque