.NET GUI - C# 与 C++/CLI
我正在编写一个小型应用程序，需要一些列表框、按钮、文本框。 它将与 Boost、MySQL 等 C++ 静态库链接。 该项目需要win32功能。 我认为 Winforms 会很好（MFC 和 CodeJock 需要太多时间）。
所以 C++/CLI 似乎非常适合这项工作。 只需将标准 C++ 与 GUI 结合使用即可。 然后我遇到建议您用 C# 编写 GUI 的线程。 然后使用 p/Invoke（慢速）或 C++/CLI 接口连接到标准 C++ DLL。
示例： http:// Social.msdn.microsoft.com/Forums/en-US/clr/thread/6ae877ac-07b4-4d26-8582-de475ee9a5cb
为什么？ 在 winforms GUI 中使用 C# 而不是 C++/CLI 有什么优势（它们看起来相同，命令也相同）。 使用 C++/CLI 可执行文件而不是标准 C++ 可执行文件有什么缺点。 我可以理解跨平台兼容性是否是一个问题，但是您可能根本不使用托管功能（GUI 除外）。
我不明白为什么你会使用 C#，然后用“引擎 DLL”将其分离。 当然，除非“引擎 DLL”也被用于其他应用程序。
谢谢
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我对此感到好奇，因此通过 Visual Studio 2008，我使用 C++/CLI 作为语言创建了一个新的 Windows 窗体应用程序项目。 它做的第一件事就是抛出一个错误。 所以我认为这表明这个东西还没有完全准备好使用。 也许我没有给它足够的机会！
每当我尝试打开向导创建的 Form1.h 文件时，就会发生这种情况。
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!
This happens whenever I try to open the wizard-created Form1.h file.
我可能会面临被否决的风险，但是，如果您的大部分代码已经用 C++ 编写
并使用 C++ 功能，用 Native C++ 编写 GUI 不是更简单吗？
您不必使用 MFC 来创建 GUI。 看看 Qt4，他们有很好的教程
因此您可以在几个小时内开始用 C++ 编写 GUI。
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.
是的，大多数自动建议使用 C# 而不是 C++ 的人似乎都认为您已经了解 C# 或者愿意投入时间来学习它。
我不明白对 C++/CLI WinForms 的仇恨到底是什么。
至少如果您想移植现有的 C++ 代码，它可以完成工作。 至少我已经使用 WinForms/CLI 在现有的 C++ 中添加了 GUI。
是的，如果我从头开始，我可能会使用 C#，因为：
1 我已经了解 C
2 我知道使用 C 编写代码更容易、更快
但是就像我说的，如果您已经掌握了 C++ 代码，您真的想开始吗从头开始？
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?
我认为关于这个问题的大多数建议都围绕这样一个事实：C# 是比 C++/CLI 更好的创建 .NET 应用程序的环境。 语法更清晰，工具更好 - 无论是在 Visual Studio 中还是来自第三方。 您将从几乎都更熟悉 C# 的开发人员那里获得更多、更好的支持。
C++/CLI 应用程序与标准 C++ 有很大不同，其中包含 ^ 和 % 字符，至少我觉得它不是 C++。
大多数建议也是从您想要创建 .NET 应用程序的角度出发，而 C++/CLI 更多地用作粘合层。 每当我使用 C++/CLI 时，我总是不情愿地使用它，而且几乎总是因为某些第三方库传递了许多复杂的 C/C++ 对象。 使用 C# 和 P/Invoke 时，您通常必须创建类来镜像您所连接的软件的 C++ 头文件中的结构和类。 保持这些同步是一项劳动密集型工作，而且很容易犯错误。 此外，弄清楚如何用指向结构体数组的结构体的指针来编组结构体将使您的大脑融化！
我的一般建议是使用 C#（或 VB.NET）为您的应用程序创建尽可能多的代码。 当您需要调用Win32 API和/或第三方SDK有限且接口和参数简单时，请使用P/Invoke。 如果无法做到这一点，请使用 C++/CLI 作为粘合层。
在团队环境中，您的开发人员同事会感谢您将 C++/CLI 的使用限制在绝对需要的地方。 C++/CLI 专业知识并不常见。
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.
就我个人而言，我喜欢 C++/CLI，但我仍然宁愿用 C# 编写 UI。
C++/CLI 对于直接使用 Win32 或与遗留代码交互非常有用，但是当涉及到 UI 代码时，它对于我的喜好来说有点过于冗长。 C# 中的 WinForms UI 代码既漂亮又简单（大多数情况下，哈哈）。 用 C++ 编写 UI 代码几乎总是很混乱（看看 MFC 就知道了）。
为什么不在一个 C# 程序集中创建 UI，并将所有较低级别的代码放入 C++/CLI 程序集中？ C++/CLI 的好处是您可以创建一个 C# 代码可以轻松调用的托管层。 然后，该管理层可以轻松地将调用转发到直接 C++ 或 C 代码的本机层。
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.
他们看起来不一样。 我认为 C# 更干净并且有一些有用的抽象。 对于 C# 或 VB.net 的工具支持也明显更好。
查看此处的示例比较
并且不要忘记高效Lambda 表达式、LINQ、类型推断等语言功能往往首先出现在 C# 上，然后很快就会渗透到 VB.net，但很少会渗透到 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.
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.