问题
Currently I am split between these two languages. I'm almost halfway through programming my current application which needs to be very fast. It calculates insulated glass structures of any kind in multiple load-conditions.
I just do not know if its the right choice to write it in C++/CLI. On the internet for example I never even read the name "C++/CLI" but everyone advises to learn C#.
What are really the downsides of C++/CLI? I have gathered from my reading that it is doomed to be deprecated in the next few years. Is this true? And if there are some, are they so bad it is really necessary to switch to C#?
The only thing currently speaking against C# is that I have C-code which I need to access and I am not able to create .Dll's due to security issues and hack prevention. (The program will be very expensive)
What other opportunities do I have in order to write a fast GUI running on windows (also with 3D Animation and Multi-Core and even Graphic-Core Processing)?
回答1:
Searching for higher performance, I had ported a great deal of C#/WPF UI to C++/CLI (which has evolved to C++/CX as it relates to WinRT). It is important to remember that it isn't C++, but a set of managed extensions for the C++ language to support .NET. I love low level UI coding, and often wrote most controls in WPF, deriving from DrawingVisual or UIElement, depending on user input requirements.
I personally disliked the 'extensions' (like using hats ^) and found it very unnatural. I didn't see big gains from C# (and the newly released 4.6 looks to have made additional improvements). I personally think C++/CLI will soon be a thing of the past. I am definitely not alone with my dislike towards C++/CLI, and guys like Kenny Kerr have had a big impact on the entire matter. In fact, I predict MS will adopt his library and sunset C++/CLI altogether.
After dumping the whole project, and migrating to pure C++ / Direct2D. I grossly underestimated the development time, but I found HUGE gains. It is not an easy road, as you will be writing your own controls (textboxes and all). However now there is Win2D (wrapper of Direct2D) which provides those controls, and looks to be a great solution (however it wasn't available when I began, and I have no intention of changing now).
I couldn't be happier with my decision now, but I certainly had some doubts along the way, and wouldn't necessarily recommend that effort, unless your heart is really in it for the long haul. Otherwise, stick with what you know.
EDIT: And by the way, any of those who say C#/WPF is just as fast as C++/DirectX is either in denial or delusional. And with some of the optimizer improvements included in VS2015, you will be amazed at the small foot-print, and performance that will result. And removing the .NET dependency is a huge weight loss, while making it very difficult for those who intend to reverse engineer your product.
EDIT 2: If you do not currently know C#/WPF, then of course avoid it, especially since you have existing C code (which is why I upvoted Dave's answer). And if performance is critical, now is a perfect time to jump into DirectX 12 (best possible performance from MS tech). Good luck, sounds like a fun project.
EDIT 3: As stated above (with respect to Kenny Kerr), here is a recent announcement which will likely begin the new era, and sunset C++/CLI and C++/CX.
回答2:
The 'problem' with C++/CLI is that C++ is one of the most complicated higher level languages (though some would argue it isn't a high level language) around. So creating an application, especially GUI based, is a lot harder than in C# or another similarly modern language. It's also a lot easier to make drastic mistakes which are very hard to debug and track down, though the CLI part of that combination does make it easier, or take care of some of the problems that you would encounter.
On the other hand it is in some ways easier to optimise, if it is even needed at all, and interop with C code is very easy. On the other hand it is also very easy to write very poorly performing C++ code if you don't know what you are doing. So if you don't know C++, I would recommend staying away from it for a critical project, as it would be doubtful that you would deliver a working program let alone a fast one.
C# can be just as fast, but there are multiple things that get in your way, the biggest of which is the auto running garbage collection which can cause intermittent performance issues. So it is easier to get working, but may be harder to get performing well enough. C interop seems easy, though I haven't tried it. This answer seems good (top answer in the google search 'C code from C#'): Is it possible to call a C function from C#.Net
回答3:
To answer your last question perhaps you should be looking at QT.
C++/CLI is good for gluing together native things and .NET things, but it's not simple even for experienced C++ programmers (because it isn't really C++).
回答4:
I'm sometimes of the opinion that if we could turn back time, there might not be a C#, as C++/CLI could (have) done the job. But by the time we got C++/CLI (Visual Studio 2005, Managed C++ was horrible), C# was already quite successful.
I'll have to look for the reference, but the current (or, at least recent) guidance from Microsoft was that C++/CLI is now intended to only be used for "interop" scenarios. This is a rather large step back from the initial goals when C++/CLI was first introduced; it was originally intended to be a first-class .NET language next to C# and VB.NET.
My rule-of-thumb is that if I have to duplicate header files in C#, then C++/CLI might be preferable. Otherwise, if it's a "simple" (strings, ints, doubles) P/Invoke to unmanaged code, just go with that.
回答5:
This idea that a C DLL is less secure than a CLI DLL -- where did that come from? It's completely false in my mind. C DLLs are much more difficult to reverse engineer than any IL code.
I've used C++/CLI to interop to a C library. I've also used the C# interop stuff (aka, DllImport) for several projects (like this one). DllImport is infinitely easier than C++/CLI. And it allows you to keep the "Any CPU" target; just include a native DLL for each target platform and load the right one at runtime. The pinning in CLI is difficult to get right. You end up with a lot of try/finally kind of stuff. It's a weird mix of operators.
来源：https://stackoverflow.com/questions/32001643/c-cli-or-c-sharp-for-creating-fast-modern-and-responsive-gui-on-windows