Reputation: 3933
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
Upvotes: 8
Views: 7521
Reputation: 573
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:
But like I said if you already got the C++ code laying around do you really want to start from scratch?
Upvotes: 0
Reputation: 31281
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.
Upvotes: 0
Reputation: 5725
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.
Upvotes: 2
Reputation: 3504
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.
Upvotes: 17
Reputation: 26354
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.
Upvotes: 4
Reputation: 116764
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.
Upvotes: 0