windows .NET GUI - C# 与 C++/CLI

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

提问by Eric Muyser

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).

我正在编写一个需要一些列表框、按钮、文本框的小应用程序。它将与 Boost、MySQL 等 C++ 静态库链接。项目需要win32功能。我认为 Winforms 会很好（MFC 和 CodeJock 需要太多时间）。

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.

所以 C++/CLI 似乎非常适合这项工作。只需在 GUI 旁边使用标准 C++。然后我遇到了建议您改用 C# 编写 GUI 的线程。然后对标准 C++ DLL 使用 p/Invoke（慢）或 C++/CLI 接口。

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

示例：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).

为什么？在 Winforms GUI 中使用 C# 而不是 C++/CLI（它们看起来相同，命令相同）有什么优势。使用 C++/CLI 可执行文件而不是标准 C++ 可执行文件有什么缺点。我可以理解跨平台兼容性是否是一个问题，但是您根本无法使用托管功能（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.

我不明白你为什么要使用 C#，然后用“引擎 DLL”把它分开。当然，除非“引擎 DLL”也被用于其他应用程序。

Thanks

谢谢

回答by Jeremy

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# 只是一个比 C++/CLI 更好的环境来创建 .NET 应用程序。语法更简洁，工具更好 - 无论是在 Visual Studio 中还是来自 3rd 方。您将从几乎都更熟悉 C# 的开发人员那里获得更多更好的支持。

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

C++/CLI 应用程序与标准 C++ 有足够的不同，带有所有那些 ^ 和 % 字符，我至少觉得它不是 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!

大多数建议也是从您想要创建 .NET 应用程序的角度来看的，而 C++/CLI 则更多地用作粘合层。每当我使用 C++/CLI 时，我都会不情愿地并且几乎总是因为某些第三方库有许多复杂的 C/C++ 对象传递。使用 C# 和 P/Invoke 时，您通常必须创建类来镜像所连接软件的 C++ 头文件中的结构和类。保持同步是劳动密集型的，而且很容易犯错误。此外，弄清楚如何使用指向结构体数组的结构体的指针来编组结构体会让你的大脑融化！

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.

我的一般建议是使用 C#（或 VB.NET）为您的应用程序创建尽可能多的代码。当您需要调用 Win32 API 和/或 3rd 方 SDK 有限且接口和参数简单时，请使用 P/Invoke。如果不可能，请使用 C++/CLI 作为粘合层。

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.

在团队环境中，您的开发人员同事会感谢您将 C++/CLI 的使用限制在绝对、肯定需要的地方。C++/CLI 专业知识并不常见。

回答by Rob

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

就我个人而言，我喜欢 C++/CLI，但我仍然更愿意用 C# 编写我的 UI。

C++/CLI is greatfor 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).

C++/CLI非常适合直接使用 Win32 或与遗留代码交谈，但在涉及 UI 代码时，我不喜欢它有点过于冗长。C# 中的 WinForms UI 代码很好而且很简单（在大多数情况下，哈哈）。用 C++ 编写 UI 代码几乎总是一团糟（看看 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.

为什么不只在一个 C# 程序集中创建您的 UI，并将您所有的低级代码放在一个 C++/CLI 程序集中？C++/CLI 的好处在于您可以创建一个 C# 代码可以轻松调用的托管层。然后，该托管层可以轻松地将调用转发到直接 C++ 或 C 代码的本机层。

回答by marr75

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

在 Winforms GUI 中使用 C# 而不是 C++/CLI（它们看起来相同，命令相同）有什么优势？

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.

他们看起来不太一样。在我看来，C# 更简洁，并且有一些有用的抽象。对于 C# 或 VB.net 的工具支持也非常好。

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.

并且不要忘记诸如 Lambda 表达式、LINQ、类型推断等富有成效的语言功能，这些功能往往首先触及 C# 并很快渗​​透到 VB.net，但很少能找到 C++/CLI。

回答by Artyom

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...

我正在编写一个需要一些列表框、按钮、文本框的小应用程序。它将与 Boost、MySQL 等 C++ 静态库链接。项目需要win32功能...

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 NativeC++.

我可能会面临被否决的风险，但是，如果您的大部分代码已经用 C++ 编写并使用 C++ 功能，那么用本机C++编写您的 GUI 会不会更简单。

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.

您不必使用 MFC 来创建 GUI。看看Qt4，他们有很好的教程，所以你可以在几个小时内开始用 C++ 编写 GUI。

回答by daveangel

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:

是的，似乎大多数自动建议使用 C# 而不是 C++ 的人都假设您已经了解 C# 或愿意花时间学习它。我不明白对 C++/CLI WinForms 的所有仇恨是什么。至少如果您想移植现有的 C++ 代码，它就可以完成工作。至少我已经使用 WinForms/CLI 将 GUI 添加到我现有的 C++ 中。是的，如果我从头开始，我可能会使用 C#，因为：

1 I already know C

1 我已经知道 C

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

2 我知道使用 C 进行编码会更容易、更快捷

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

但是就像我说的，如果你已经掌握了 C++ 代码，你真的想从头开始吗？

回答by Daniel Earwicker

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!

我对此感到疑惑，因此使用 Visual Studio 2008 创建了一个新的 Windows 窗体应用程序项目，使用 C++/CLI 作为语言。它做的第一件事就是抛出一个错误。所以我认为这表明这些东西还没有完全准备好使用。也许我没有给它足够的机会！

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.

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.

每当我尝试打开向导创建的 Form1.h 文件时，就会发生这种情况。