Convert C# Applicaton to C++

Firstly, you are aware of Mono right? This could ease your transition in this direction.

Few people in linux write in C#, so it is unlikely that you will have a magic bullet here -- its just not a common problem AFAIK. I have not written any C# myself though.

You might be able to identify many repetitive idioms in your code and be able to cook up some regexps to sort them out, or some function wrappers to do the job.

Your comment "Provide an API to X" is a bit odd -- using X directly sounds like a world of pain -- you may want to use a widgets system, like GTK, QT or wxWidgets. This will provide you with all the basic stuff like buttons textboxes etc etc. Otherwise you have to draw them yourself in X -- which you probably don't want to do.

If you have existing C++ knowledge installing a compiler is trivial -- just install the build-essential package, which includes things like make, autotools, g++ etc etc.

You may want to also read about Gnote -- it is a port of the application "tomboy", a note taking application from c# to c++. The resultant system was near identical, took about a month, and used a fraction of the resources, and was overall much more efficient.

http://www.figuiere.net/hub/blog/?2009/07/27/680-why-i-did-write-gnote

If you tell us why you want to convert a program from C# to C++, that might make a more specific answer possible.

On Fri, 2011-02-18 at 09:25 +0000, Eliah Kagan wrote:
> Your question #145519 on Ubuntu changed:
> https://answers.launchpad.net/ubuntu/+question/145519
>
> Eliah Kagan requested for more information:
> If you tell us why you want to convert a program from C# to C++, that
> might make a more specific answer possible.
>
I have a C++ compiler, but, not a c#. I want to include part of the C#
code in a larger C++ application.

tomdean

c# is normally used as a byte-compiled language, not fully compiled one. Mono will allow you to build and run C# applications, within a given particular subset of the .net libraries.

You can call C++ from c#,
http://www.mono-project.com/DllImport

but I am not sure about the other way around. C# is managed code, and needs to invoke a byte-compiled language interpreter/VM -- its like asking to call java code from C++ -- just not going to be easy/work, due to the need to build in all the baggage that comes with these languages.

What you can do however, is communicate using standard IPC (inter-process communication) methods, like your filesystem! You can use the exec command to fork off the underlying C# application, have it do what you need, then read the result back. If you want to get fancy, then you might be able to do this through pipes.

Intertwining the two is just going to be complicated. Its hard enough to call c++ from C#, and c++ is a native program -- all you have to do is get the instructions into the chip. C# you first have to get the VM onto the chip, have it locate the language runtime, then have it locate your code's entry point. Pain.

On Fri, 2011-02-18 at 19:28 +0000, mycae wrote:
> Your question #145519 on mono in ubuntu changed:
> https://answers.launchpad.net/ubuntu/+source/mono/+question/145519
>
> Status: Open => Answered
>
> mycae proposed the following answer:
> c# is normally used as a byte-compiled language, not fully compiled one.
> Mono will allow you to build and run C# applications, within a given
> particular subset of the .net libraries.

I want to convert the C# source code to C++ source code. I have a
larger application in C++ that I want to have the functions implemented
in C# included. The C# application is five files:

graph.cs --> graph.cc
calc.cs --> calc.cc
translate.cs --> translate.cc
render.cs --> render.cc
misc.cs --> misc.cc

After converting the C# source code to C++ source code, I will compile
the entire application with C++.

Looks like I will have to type it in, converting as I go. The C# source
code is 1000+ lines!

tomdean

Not only can you invoke C++ from C#, but you can invoke C# from C++, and you can even do both with a single executable file (though often it is preferable to used mono as a shared library rather than have a huge executable size):

http://www.mono-project.com/Embedding_Mono

On Fri, 2011-02-18 at 20:02 +0000, Eliah Kagan wrote:
> Your question #145519 on mono in ubuntu changed:
> https://answers.launchpad.net/ubuntu/+source/mono/+question/145519
>
> Status: Open => Answered
>
> Eliah Kagan proposed the following answer:
> Not only can you invoke C++ from C#, but you can invoke C# from C++, and
> you can even do both with a single executable file (though often it is
> preferable to used mono as a shared library rather than have a huge
> executable size):
Please Read my last post.

I did read your last post before I made my last post. By embedding mono, you can expose your C# functions as C++ functions and call them from C++ code. You can even (often) succeed at passing C++ callbacks to them (which are automatically marshaled as .NET/Mono delegates), if you are unfortunate enough to have to deal with that sort of thing.

If you insist on converting from C# to C++, which as you know is both a translation (new language) and a port (new platform, no longer the CLR), then go ahead, but that is usually time-consuming and, from a business perspective, often not worth the effort. If you only have about 1000 lines, it shouldn't be too bad...but remember, there are some fundamental differences between the two *platforms* that you may have to take into account, including the typical absence of garbage collection in native C++ programs; differences in the way locales (as they are called in C++/*nix) and cultures (as they are called in C#/.NET) are handled, which is often very relevant to the printing of numbers as strings; differences in the way multi-threading and synchronization are accomplished; and often, differences in string representation. (Of course, you might have to deal with these differences if you chose to embed mono, too. But they'd be *all* you had to deal with...and to an extent they are handled automatically by the .NET/Mono framework's marshaling capabilities.)

Then, after translating from C# to C++, you'll have to test your new code much more extensively than you'd probably have to, if you chose to embed Mono.

I'm not saying that your approach is necessarily the wrong choice. Your code will very likely run faster once you translate it to C++/native from C#/CLI, your API will be more consistently C++-like, and by not embedding mono, you're either pulling in fewer dependencies or substantially reducing the size of your own executable or library (or both).

On Sat, 2011-02-19 at 00:55 +0000, Eliah Kagan wrote:
> Your question #145519 on mono in ubuntu changed:
> https://answers.launchpad.net/ubuntu/+source/mono/+question/145519
>
> Status: Open => Answered
>

Thanks for the answer. I sort-of knew I would have to rewrite it. But,
I thought, "I am not the first...", hoping for a tool.

This will be distributed beyond my control, to different platforms, so,
embedding is not the best choice. Not a commercial application.

Thanks

My intention is not to second-guess your judgment as the actual developer of this software...but you (and other people stumbling upon this question) should be aware that Mono is multi-platform (for example, it runs on Windows too), so an application that embeds Mono might not suffer for lack of portability as a consequence. Furthermore, you may simply be able to take advantage of C++/CLI on Windows to make a "mixed-mode" executable (using the Microsoft CLR) that does the same work as a Mono-embedding executable (without requiring Mono).

Of course, if this (I mean the existing C++ code) is a library, or command-line program, and already has virtually unlimited portability, then embedding Mono certainly would reduce that.

A Google search turns up some products that purport to perform conversions from C# to C++, and many of them (can) convert to native C++ (not C++/CLI). However, their descriptions don't sound all that encouraging. (And I don't see any that aren't payware...but you could, and perhaps already have, look[ed] much harder than I have.) For example, they tend not to refactor try...finally clauses and using statements/blocks into corresponding RAII constructs. One advertises that it *occasionally* is able to produce delete statements to perform deallocation of globally-referenced objects at the appropriate time. They tend not to attempt to convert ": this(...)" calls in initialization lists, perhaps since doing so would typically involve a degree of refactoring and (even then) code repetition that programmers wouldn't like to have foisted upon them automatically. This is by no means intended as an exhaustive list of commonly untranslated constructs.