Win32控制台应用程序与CLR控制台应用程序 [英] Win32 Console app vs. CLR Console app

查看:426
本文介绍了Win32控制台应用程序与CLR控制台应用程序的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在开发一个C ++项目,我不打算使用.NET库或工具开发或部署,这意味着我将使用Visual Studio Win32控制台应用程序创建它是有意义的。但是,我听说在Visual Studio下使用CLR应用程序时的调试功能更强大。所以我有几个问题:


  1. 这是真的,有一个CLR应用程序与Win32应用程序添加功能,即使您没有使用任何.NET库或其他资源也可以执行此操作?


  2. 如果是这样,我仍然可以将项目开发/编译为CLR项目,以利用这些,即使我将开发一个纯C ++项目使用STL等,而不是利用任何.NET功能?



div class =h2_lin>解决方案

底线回答,如果你从不打算在你的应用程序中使用CLR或任何.Net对象,只需使用一个正常的Win32 C ++库。做任何其他事情会让你痛苦的道路。



现在,为了回答关于调试的原始问题,使用CLR进行调试与调试正常的C ++应用程序相比具有一定的优势。从Visual Studio 2005开始,C#和VB.Net开始专注于使变量显示在locals / autos / watch窗口中更有价值。它主要通过引入.Net属性(如DebuggerDisplay,DebuggerTypeProxy和visualizer框架)来完成。



如果你不使用任何.Net类型,你将得不到这些好处。



C ++表达式计算器不利用任何这些。它有自己的自定义类型显示的方法。但是它不像属性样式那么有特色(或潜在危险),因为它不允许代码在debugee进程中运行。



这不是说调试C ++提供了不好的体验。它只是不同的,有许多STL容器类型的更好的显示。



调试CLR应用程序也有一些缺点。例如,调试优化的代码几乎是不可能的,因为JITer会隐藏局部变量,参数和经常this。调试一个类似构造的C ++应用程序也可能令人沮丧,但你可以总是抓住寄存器和disamebly看到发生了什么。对CLR应用程序进行相同操作最好是很困难的。


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:

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

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

解决方案

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.

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.

If you don't use any .Net types though, you will get none of these benefits.

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.

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.

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.

这篇关于Win32控制台应用程序与CLR控制台应用程序的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆