.NET GUI - C# vs C++/CLI

Question

I'm writing a small app that requires a few listboxes, buttons, textboxes. It'll be linked with Boost, MySQL, etc. C++ static libs. The project requires win32 functions. I figure Winforms will be fine (MFC and CodeJock require too much time).

So C++/CLI seems perfect for the job. Just use standard C++ along side the GUI. Then I run across threads suggesting you write your GUI in C# instead. Then use p/Invoke (slow) or a C++/CLI interface to your standard C++ DLL's.

Example: http://social.msdn.microsoft.com/Forums/en-US/clr/thread/6ae877ac-07b4-4d26-8582-de475ee9a5cb

Why? What advantage is there in using C# for your winforms GUI instead of C++/CLI (they look the same, the commands are the same). What disadvantage is there in using C++/CLI executable instead of standard C++ executable. I can understand if cross-platform compatibility was an issue, but then you could simply not use managed features (other than the GUI).

I don't understand why you would use C#, and then go so far to separate it with an "engine DLL". Unless of course the "engine DLL" was being used for other applications as well.

Thanks

Answer 1

I think most recommendations with regard to this question center around the fact that C# is just a better environment to create .NET applications with than C++/CLI. The syntax is cleaner, the tooling is better - both within Visual Studio and from 3rd parties. You will get more and better support from developers who will almost all be more familiar with C#.

C++/CLI applications are different enough from standard C++ with all those ^ and % characters that I at least feel it is NOT C++.

Most advice is also coming from the point of view that you want to create a .NET application and C++/CLI is used more as a glue layer. Whenever I have used C++/CLI, it was grudgingly and almost always because some third-party library had many complex C/C++ objects that it passed around. When using C# and P/Invoke, you often have to create classes to mirror the structs and classes that are in the C++ header files of the software you are interfacing with. Keeping those in sync is labor intensive and making mistakes is easy to do. Furthermore, figuring out how to marshal a struct with pointers to structs of arrays of struct will make your brain melt!

My general advice is to use C# (or VB.NET) to create as much code as feasible for your application. Use P/Invoke when your need to call the Win32 API and/or 3rd party SDKs is limited and the interfaces and parameters are simple. Use C++/CLI as a glue layer when this is not possible.

In a team environment, your fellow developers will thank you for limiting your usage of C++/CLI to only where it is absolutely, positively required. C++/CLI expertise is just not that common.

Answer 2

Personally, I love C++/CLI, but I'd still rather write my UI in C#.

C++/CLI is great for working directly with Win32 or talking to legacy code, but it's a little too verbose for my liking when it comes to UI code. WinForms UI code in C# is nice and simple (for the most part, haha). Writing UI code in C++ is almost always messy (just look at MFC).

Why not just create your UI in one C# assembly and put all of your lower-level code in a C++/CLI assembly? The nice thing about C++/CLI is that you can create a managed layer that your C# code can easily call. That managed layer can then easily forward calls to a native layer of straight C++ or C code.

Answer 3

What advantage is there in using C# for your winforms GUI instead of C++/CLI (they look the same, the commands are the same)?

They don't look the same. C# is in my opinion cleaner and has some useful abstractions. Tooling support is massively better for C# or VB.net also.

Look here for an example comparison

And don't forget productive language features like Lambda Expressions, LINQ, type inference, etc. which tend to hit C# first and trickle down to VB.net soon enough but rarely find their way down to C++/CLI.

Answer 4

I wondered about this, so with Visual Studio 2008 I created a new Windows Forms Application project using C++/CLI as the language. The first thing it did is throw up an error. So I took that as an indication that this stuff isn't quite ready for use. Maybe I'm not giving it enough of a chance!

 The file 'c:\\source\\Test\\Test\\Form1.h' does not support code parsing or generation because it is not contained within a project that supports code. 

This happens whenever I try to open the wizard-created Form1.h file.

Answer 5

I'm writing a small app that requires a few listboxes, buttons, textboxes. It'll be linked with Boost, MySQL, etc. C++ static libs. The project requires win32 functions...

I probably get risk to be downvoted, but, if most of your code is already written in C++ and use C++ functionality, woudn't it be simpler to write your GUI in Native C++.

You do not have to use MFC to create GUI. Make a look on Qt4 , they have very good tutorial so you can start writing GUI in C++ withing few hours.

Answer 6

Yeah it seems most people that automatically suggest using C# over C++ assume you already know C# or are willing to invest time in learning it. I don't see what all the hate over C++/CLI WinForms is. At least if you want to port over existing C++ code it gets the job done. At least I've tacked on a GUI to my existing C++ using WinForms/CLI. Yeah I probably use C# if I was starting from scratch since:

1 I already know C

2 I know it's a lot easier and quicker to code using C

But like I said if you already got the C++ code laying around do you really want to start from scratch?