C# vs. C++ in a cross-platform project

Question

My team is planning to develop an application that is initially targeted for Windows but will eventually be deployed cross-platform (Mac, Linux and potentially embedded devices). Our decision is whether to use C#/.NET or generic C++ (with Qt as the user interface library). We’re projecting that by using C#, we can develop our product faster and at a lower cost due to the increase of productivity over C++, but we’re taking a gamble on whether cross-platform implementations of C# will be mature enough at the time when we want to roll out to other platforms.

Any suggestions from any of you who have been in a similar situation?

Answer 1

If you want to go cross-platform, C++ is definitely the way to go.

Edit: I am one to think you should choose your language according to your project, and not prefer a language because you are simply used to it. Although C# may offer cross-platform support, it was originaly designed to run only on Windows.

Mark Maslar has a good point too, depending on the application you want to develop, a web-based application would be completely platform independent.

Answer 2

Again a question where the answer is: It depends! (Skill of your programmers in C# and C++ and if they're really much faster in C# and so on).

Just a Remark:
The Mono Project delivers a platform (Version 2.0 supports to up .NET 3.0) which can be used on Macs or Linux systems. Including microsoft code sugar like LINQ.

Answer 3

My gut feeling here would be to go ahead and develop fully in C#. If and when you get cross-compatibility issues, rewrite the necessary sections in C/C++ DLLs/shared libraries. Apparently Mono can indeed handle shared libraries on a platform-specific basis.

Depending on what you're doing, this might end up being totally unreasonable, but you would still get to keep the rapid Windows development, and you would have to only rewrite parts of the application in C++, not the whole thing.

Answer 4

Take Java/Scala into consideration. One of the most wonderful developer IDEs IntelliJ IDEA is written in Java - take a look.

Answer 5

If you don't mind the non-native look in Windows (which is apparent even with the "windows" skin that GIMP uses), you can use Gtk# and Mono. When it comes to UI stuff, i've found Gtk# to be easier and more intuitive (from a programming PoV) than the .NET framework. On the other hand, debugging will probably be easier if you use .NET.

Answer 6

I have no experience in this scenario, so this is worth what it's worth... I would probably use .Net, but would always target Mono. This would mean a much less risk of using MS implementation of .Net and becoming inadvertently dependent on some feature still not implemented in Mono, hence destroying your portability to platforms other than Windows.

Answer 7

If you are doing C++ and the GUI is important, wxWidgets looks "Native" on all platforms. It is worth taking a look at it.

If you are all good with C# I would definitely consider it - for productivity.

Answer 8

Despite all the potential cross platform capabilities of Mono, today, C++/Qt is simply a much more mature option than either C#/WinForms or C#/Gtk# for cross-platform purposes. Any productivity gains you would get by using a higher-level language would likely be offset by dealing with limitations of Mono.

Answer 9

Potentially which embedded devices? If they won't work with .NET or Mono, you'd be cutting off the possibility if you go with C#. (It doesn't have to be an OS issue; some embedded devices have strict memory or performance limits, which .NET/Mono might exceed.)

If that isn't critical, there's a whole lot of factors to consider. Does your project use what would be standard .NET features, or are you likely to strain Mono? Is this a case of knowing C# and not C++, or do you just have better experience with C#? (If you're better with C++ than C#, then C# is not likely to give productivity benefits on one project, and you should just go C++ and get C# experience on something less cross-platform.) How important is getting a version out fast on Windows? (It could be vital to get a first mover advantage, or minor if you're doing something less time-critical.) How much will you benefit from Mac and Linux versions (usually more than their market share would indicate, since there's less competition)?

Answer 10

The approach I have taken with many cross-platform projects is to write the "core" of the project in a very portable language (C++), and then implement the UI (and anything else that is OS-dependent, e.g. some types of data access) in a language that was efficient for that task on the various platforms.

Just wanted to point out that you aren't stuck with choosing just one language.

Answer 11

Are you set on only having a single set of UI code on all platforms? I would encourage you to consider two separate UIs with a common core, there's really no substitute for a native UI.

In this case, you could go Winforms/WPF in C# for the Windows UI, Cocoa in ObjC for the OS X UI, GTK in C# for the Linux UI. All of these would use a common C# core capable of running on Mono and .NET. Mono makes it relatively painless to use with ObjC.

Answer 12

I'm developing for years cross-plateform softwares with C++/Qt.
I strongly recommend this solution for your development.
Such a solution brings you performance on ALL platforms !
Moreover, Qt isn't only a GUI framework, but brings you a complete framework for networking, DB, I/O, great support, and a very ingenious system of internationalization !
Finally, Qt provides native looking on all platforms it supports.

And about performance, is Mono / C# equivalent to C++/Qt ?

Answer 13

Jen, I'm worried about the wording of your question.

"My team is planning to develop an application that is initially targeted for Windows but will eventually be deployed cross-platform (Mac, Linux and potentially embedded devices)."

Is the plan to do cross-platform or not? I can infer that code will be initially written for Windows and then, maybe sometime later, effort will be expended in modifying the project for cross-platform capability. This will not be good for your health or your team's health! A definite business decision needs to be made here. One of the golden rules of cross-platform development is to treat all targeted platforms with absolute equality.

Can you use C# for embedded environments? Has it already been done commercially? Just curious.

"We’re projecting that by using C#, we can develop our product faster and at a lower cost due to the increase of productivity over C++" What do you mean 'projecting'? On what facts and figures are you making this projection? Do not forget that the coding effort on some projects is low as ~20% of the total effort required to bring a product to market. So the question of productivity comparison of computer languages may be not that significant. In my experience it's not productive to choose a computer language on the so-called productivity criteria.

"we’re taking a gamble" I agree with that, and gambling seems to contradict the meaning of planning. The question is: what are the risks?

Have you considered internationalisation?

Yes, I'm being critical but someone who is paying the money for this project may well be more questioning.

Book: Cross-Platform Development in C++: Building MAC OS X, Linux, and Windows Applications by Syd Logan - ISBN 032124642X Gives an idea of the issues involved.

I've been on a cross-platform and internationalised projects for Windows, Mac, and Linux using C++/Qt. The latter does well for both issues. One dis-like I have of Qt is it is not modern C++ in idiom nor does it encourage the use of modern C++ idioms. Just like MFC.

Answer 14

did you consider using python/c++/QT ?

just look at it

Answer 15

Hi Just to add with this discussion. I have developed a software with c++. I am the only developer and its 80% finish.

Now I am finding it hard to get c++ programmer and also any experience php programmer. Geting lot of c# programmer.

I know c# as well. It may take one month two convert c++ to c# (leaving some features that i feel too much to maintain).

my dislike is .net size. I looked at mono as well. Personally it is not a problem for me as i am very good in c++. But geting programmer who can do bit complex project with PHP is become hard. They are just basic web developer( the place i am looking for programer and my budget).

Personally i like c++ and love small executable size. My pririty is to sell online. On the other hand it is a server program so need one instance in a LAN.

I have to make a decision by month time as i have to start finishing this project.

You may have a look of my project type on ashnah dot com

Answer 16

If you are comitted to a multi-platform approach, I think it depends on how UI-heavy your application is. If the meat of the application is in the back end, a possibility not mentioned is to go for a blend of C++ and C++/CLI. C++/CLI gives you access to the vast .NET BCL (including UI components) so you can get to market quickly on Windows, and you can stick to vanilla C++ where this isn't needed. Then to port to another platform you only need to target the C++/CLI parts.

On the other hand, you want to seriously question the "eventually" part of the plan to migrate to other platforms. Concentrating exclusively on Windows and using .NET with C# or VB.NET gives you an easier development route in terms of the programmer competence you'll require.

Answer 17

Why not use multiple languages. Use C++ for the underlying framework which will be the core ( most work needed ) of your application and platform independent. Then you can create the UI in C# for your Windows version, and if later on you decide to port to Mac or something else, you can write it in Java or Qt or whatever language/API you decide to use. I think it's ok if the UI is platform dependent as long as the core of your application is not.

It would be better to decide right away whether or not your application will be cross-platform, but if you can't then I think a platform dependent UI with a platform-independent framework/infrastructure is a good way to go.