visual-studio Win32 控制台应用程序与 CLR 控制台应用程序
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1022072/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Win32 Console app vs. CLR Console app
提问by bsofman
I'm working on a C++ project that I don't intend to develop or deploy using .NET libraries or tools, which means it would make sense for me to create it using a Visual Studio Win32 Console application. However, I've heard that the debugging abilities when using a CLR application under Visual Studio are much more powerful. So I have a few questions:
我正在处理一个 C++ 项目，我不打算使用 .NET 库或工具开发或部署该项目，这意味着我可以使用 Visual Studio Win32 控制台应用程序创建它。但是，我听说在 Visual Studio 下使用 CLR 应用程序时的调试功能要强大得多。所以我有几个问题：
Is it true that having a CLR app vs. a Win32 app adds capabilities to your development process even if you don't utilize any .NET libraries or other resources?
If so, would I still be able to develop/compile the project as a CLR project to take advantage of these even though I'd be developing a pure C++ project using STL, etc. and not taking advantage of any .NET functionality? Or would such a project require fundamental differences that would make it non-trivial to revert back, meaning I should stick with a Win32 console app?
即使您不使用任何 .NET 库或其他资源，拥有 CLR 应用程序与 Win32 应用程序是否会为您的开发过程增加功能？
如果是这样，即使我将使用 STL 等开发纯 C++ 项目而不利用任何 .NET 功能，我是否仍然能够将项目开发/编译为 CLR 项目以利用这些？或者这样的项目是否需要根本性的差异，这将使恢复变得非常重要，这意味着我应该坚持使用 Win32 控制台应用程序？
回答by JaredPar
Bottom line answer, if you are never intending to use the CLR or any .Net objects in your application, just use a normal Win32 C++ library. Doing anything else will cause you pain down the road.
底线回答，如果您从不打算在应用程序中使用 CLR 或任何 .Net 对象，只需使用普通的 Win32 C++ 库。做任何其他事情都会让你在路上痛苦。
Now, to answer the original question about debugging, yes debugging with the CLR has certain advantages over debugging a normal C++ app. Starting with Visual Studio 2005, both C# and VB.Net began to focus on making the variable display in the locals / autos /watch window much more valuable. It was mainly done through the introduction of .Net attributes such as DebuggerDisplay, DebuggerTypeProxy and the visualizer framework.
现在，要回答有关调试的原始问题，是的，与调试普通 C++ 应用程序相比，使用 CLR 进行调试具有某些优势。从 Visual Studio 2005 开始，C# 和 VB.Net 都开始专注于使 locals/autos/watch 窗口中的变量显示更有价值。主要是通过引入DebuggerDisplay、DebuggerTypeProxy等.Net属性和visualizer框架来完成的。
If you don't use any .Net types though, you will get none of these benefits.
但是，如果您不使用任何 .Net 类型，您将不会获得任何这些好处。
The C++ expression evaluator does not take advantage of any of these. It has it's own methods of customizing type display. But it's not as featureful (or potentially dangerous) as the attribute style because it doesn't allow for code to run in the debugee process.
C++ 表达式求值器不利用任何这些。它有自己的自定义类型显示的方法。但它不像属性样式那样有特色（或潜在危险），因为它不允许代码在调试进程中运行。
That's not to say debugging C++ provides a poor experience. It is merely different and there are better displays for many STL container types.
这并不是说调试 C++ 提供了糟糕的体验。它只是不同，并且对于许多 STL 容器类型有更好的显示。
Debugging a CLR app also has certain disadvantegs. For instance, debugging optimized code is near impossible at times because the JITer will hide local variables, parameters and often "this". Debugging a similarly constructed C++ app can also be frustrating but you can always grab the registers and dissamebly to see what's going on. Doing the same for a CLR app is difficult at best.
调试 CLR 应用程序也有某些缺点。例如，调试优化代码有时几乎是不可能的，因为 JITer 会隐藏局部变量、参数和通常的“this”。调试类似构造的 C++ 应用程序也可能令人沮丧，但您始终可以获取寄存器并查看发生了什么。对 CLR 应用程序做同样的事情是很困难的。
回答by Kei
I think compiling native C++ code into CLR opens a whole can of worms. Unless you have large investment on existing C++ code and some necessity to run the code with managed types, this is something you want to avoid.
我认为将本机 C++ 代码编译成 CLR 会打开一大堆蠕虫。除非您对现有 C++ 代码进行大量投资，并且有必要使用托管类型运行代码，否则这是您想要避免的。
For example, C++/CLI is one way to bundle native C++ code right into a CLR assembly, but C++/ CLI adds non-standard syntax to C++ language, and using native C++ types mixed with managed types seems like a very tricky issue to say the least.
例如，C++/CLI 是将本机 C++ 代码直接捆绑到 CLR 程序集中的一种方法，但 C++/CLI 向 C++ 语言添加了非标准语法，并且使用与托管类型混合的本机 C++ 类型似乎是一个非常棘手的问题至少。
So, in conclusion, I would just keep it as a native app. If you have any plan of porting it to CLR and you've just started working on this project, I would seriously think of start writing in a CLR-native language like C#.
因此，总而言之，我会将其保留为原生应用程序。如果您有任何将它移植到 CLR 的计划并且您刚刚开始从事这个项目，我会认真考虑开始使用 CLR 原生语言（如 C#）编写代码。
回答by Steam
This answer copied from here - http://social.msdn.microsoft.com/Forums/vstudio/en-US/895ecb47-8b34-4a1a-a20b-fda1e5e576eb/whats-the-difference-between-clr-console-application-and-win32-console-application
What's the difference between CLR console application and win32 console application?- The former uses Common Language Runtime (in other words, .NET framework); the latter does not.
CLR 控制台应用程序和 win32 控制台应用程序有什么区别？- 前者使用公共语言运行时（换句话说，.NET 框架）；后者没有。
and I cannot using namespace System under the win32 console application model.- System namespace is part of .NET framework.
我不能在 win32 控制台应用程序模型下使用命名空间系统。- 系统命名空间是 .NET 框架的一部分。
What should I do when I want to use the namespace?- You should write a .NET application.
当我想使用命名空间时应该怎么做？- 您应该编写一个 .NET 应用程序。
and Doesn't it have input hint such as in C# model?- There is indeed no IntelliSense for C++/CLI in the existing versions of Visual Studio. If you want a .NET application, C# might be a better language choice.
并且它没有输入提示，例如在 C# 模型中吗？- 在 Visual Studio 的现有版本中确实没有用于 C++/CLI 的 IntelliSense。如果您需要 .NET 应用程序，C# 可能是更好的语言选择。
