views:

1754

answers:

6

Hi guys,

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

+13  A: 

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.

Jeremy
+1 Wise advice.
Rui Craveiro
Avoid C++/CLI if *at all* possible - as a C++CLI coder all I can say is - excellent advice. Ignore it at your peril folks!
mackenir
A: 

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.

Daniel Earwicker
Works fine for me. It also runs native C++ if you put it on /clr and turn off /clr:pure. So you start with a nice Winforms UI, and use your normal C++ code. Of course I $10 bet I'll run into troubles in a few days with libraries/etc. and have to switch to C# UI or Qt UI.
Eric Muyser
+3  A: 

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.

unforgiven3
That's pretty much exactly what my question was, why create the UI in C# and create the C++/CLI managed layer to call native C/C++ code. So basically the difference is a better/cleaner syntax for UI scripting and as someone else pointed out the C# UI has better tooling support.
Eric Muyser
+2  A: 

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.

marr75
A: 

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.

Artyom
WTL is another good choice for a native Windows UI.
unforgiven3
I've considered Qt, and in most cases you would be absolutely correct. This particular project is just a little too small to start learning Qt4. Plus I'd like to learn a bit more VS-oriented stuff. If I make a second version I will probably switch (another reason except for the UI I'm not using managed code).
Eric Muyser
A: 

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?

daveangel
One of the biggest problems of the C++/CLI compiler is, that it is NOT a superset of C++. If you start using advanced C++ stuff (like templates or some nice stuff from boost) the C++/CLI just runs into several problems. In that case you have to use the pImpl-Idiom, so that for your advanced C++ the standard C++ compiler will be called. This leads to much boilerplate code making the C++/CLI far less usable as i wished.
Oliver