我学习了使用Visual C和Win32 API进行Windows编程的方法。如今,似乎大多数应用程序都是使用C#在.NET中开发的。我了解到,大多数时候本机代码和托管代码之间的性能差异不大。所以我想知道,如果我今天要开始编写一个新的桌面应用程序,除了我更熟悉C的事实以外,是否有其他原因我可能想用非托管C来编写它? .NET的?使用C和本机代码还有一些优势吗?还是在Windows平台上用.NET或多或少地替代了该方法?
我当然知道,编写底层设备驱动程序和类似程序的人不会在.NET中做到这一点。我问的是典型的不直接进行硬件调用的面向客户端的应用程序。
- 如果决定是在Win32和.Net之间...去.Net,那么会有几个人抱怨他们的平台没有.Net ...但是,如果您是为Win32编写的,那么这个跨平台不是问题。
-
我仍然定期在c win32中进行开发-包括全新的应用程序。我们的大多数程序本质上都是图形化的,几乎没有库存UI功能。我发现那些诅咒非托管内存的人经常只是在重复他们所听到的,而实际上并没有在c中经历过。我更喜欢"更接近硬件",以优化某些算法。另外,我将纠正一个大的误解-win32的学习曲线比.NET和C#少(假设您有使用c的经验)。参见-charlespetzold.com/pw5/index.html。 win32可以轻松安装/运行所有版本。
-
抱歉,但是我很少看到.NET应用程序在起作用。当今大多数Windows程序都是用Win32API / MFC / Delphi / C Builder / wxWidget / Qt编写的。
IMO对于小型可下载应用程序,最重要的一项是本机代码不需要.NET运行时。尽管宽带变得越来越普遍,但并不是所有人都拥有宽带。
有些人可能会失望地看到您的2 MB应用程序实际上需要另外20MB的框架下载和繁琐的安装过程才能运行。如果他们不确定一开始是否真的需要您的应用程序,则可以在尝试使用竞争产品之前将其删除。
-
我希望我可以再投票一次。当我想尝试一个新的应用程序并要求我安装一个尚未安装的运行时时,我立即尝试其他方法。
-
您多久安装一次新版本的.NET运行时或JRE?我认为我是在2008年8月安装.NET 3.5SP1的。
-
Olli:您是一名开发人员,这使您成为计算机用户的精英。除非您的客户也是开发人员(尤其是如果他们是很少使用计算机的没有经验的用户),那么大约一半的客户可能未安装运行时。
-
一个人可以引导框架-但这会将您的2mb应用程序变成20mb应用程序。好处是用户不知道他们正在安装框架。
-
作为我的用户,我希望安装程序在必要时为我下载并安装框架,以使原始下载不会因框架而肿。这样,如果我已经有了框架,则可以更快地下载应用程序。但是,它还远非完美。本地应用程序绝对是更好的选择。
-
有时我需要编写一个小工具,以使其尽可能在最多的机器上可执行。我倾向于为此使用C。当.NET出现时,我希望使用最低的.NET版本是此类工具的好策略,但绝对不是-.NET 1.0 / 1.1是过时的,并且在新版本的Windows上默认未安装.NET 2.0。最后,我确定C是最佳选择,但有时当特定工具更易于在.NET中编写时(我知道价格-较难或无法在较旧的计算机上使用),我有时会出于懒惰而选择.NET 3.5。 。
-
性能(某些情况下,例如图形)
-
内存占用(如Mancuso所说)
-
使用现有库
-
无需运行时
-
更精细的控制
列举一些。
但是,您可能还想从相反的angular看问题,以公平地评估要使用的语言。
此外,您可以使用C / CLI合并本机代码和.net代码。
如果您的应用程序无需安装即可运行(即,如果您不能或不应该执行诸如安装.NET框架之类的操作),则不能指望Windows机器上的.NET( Vista之前的版本)。许多实用程序应用程序都可以归为此类。
我建议使用托管代码编写每个桌面应用程序。 .NET / C#是一个很好的平台。
我的原因:
性能损失可以忽略不计。如果您不相信我,请使用Google进行基准测试。更重要的是代码本身。您可以用C或.NET / C#编写O(n ^ m)算法。如今,JIT引擎非常成熟。
当涉及单元测试,模拟和重构时,非托管C的主要缺点。这是非常麻烦和僵化的。反射允许托管代码使这些事情变得非常方便。
部署是一个小问题。但是,创建一个用于检查必要的.NET前提条件并自动安装它们的安装程序是一件容易的事。
编译更快,没有链接器!当您编辑代码时,它甚至会在后台发生。
.NET库支持比STL,MFC和boost更佳,更干净。
没有头文件和宏。它们只是容易出错。
安全!再见缓冲区溢出,指针错误,未初始化的变量...
例外情况。清除.NET中的异常层次结构。 C异常被弄乱了。
-
没有什么比真相更遥远。运行的性能损失是一个受管理的环境。您几乎无法控制内存的管理方式,这对于需要实时性能的应用(例如视频游戏)来说是一场灾难。托管解决方案通常最适合企业应用程序。
-
而且您只能使用Windows解决方案。对于所有这些Mac用户来说太糟糕了...
-
授予非托管C并非在每种情况下都有意义。但是,按照原始问题的意图,它在某些情况下仍具有其优势。从所有这些注释中,您会认为Unmanaged C不再存在(不是真的)。
-
.Net有跨平台且仍受管理的替代方案(例如Mono,Java)。
-
@James,授予C在视频编解码器,视频游戏和实时场景中占有一席之地。但绝对不适用于桌面应用程序,Web应用程序,业务应用程序等。
-
@wdu,编写可移植的本地C / C应用程序是妖术。这需要很大的努力。使用mono / .NET和Java可以轻松实现相同的目的。
-
这个答案有很多优点,但是我接受了James Atkinson的答案,因为它可以更直接地回答问题。我真正想知道的是"非托管C仍然在哪个地方拥有.NET世界"。
-
我同意詹姆斯的看法。 .net应用程序的内存开销很大。查看Qt(现在与LGPL一起使用)以获得一个好的非托管跨平台解决方案。
-
同样,在这一点上,我不能完全不同意。是的,由于GC会产生开销,但是在具有约4GB RAM的现代PC上,谈论标准台式机应用程序中的内存问题毫无意义。非托管代码中的内存处理容易出错,并且会花费时间并因此而产生金钱。
-
那些保存托管代码的家伙无法处理游戏,真的需要签出XNA。 Java中的真正3D游戏很烂,但是XNA令人惊叹且易于使用。
1,因为不需要在目标计算机上安装.NET软件包。这仍然是一个大问题。
当所有计算机都具有mono或NET时,没什么大不了的。
如果您可以负担得起对堆栈的依赖,请使用.NET
现代,优雅,强大,因此可以更快地开发。
但是要意识到,您已将应用程序链接到它-语言和框架,如果您预见到将来可能希望摆脱这种情况的情况,那么请三思而后行。
Win32既旧又笨拙,但是它几乎可以在没有附加依赖项的任何Windows版本上运行,并且您的代码可以是纯净的,可移植的C / C。
内存占用量。但是,除非您为严重的机器内存问题而开发,否则对于大多数应用程序来说,这实际上不是问题。
- .NET倾向于"占用"内存,并且不会将其释放回OS,除非OS的可用内存低于阈值。 \\'好吧,如果您的应用实例很少并发运行,并且使用了大部分资源。在其他情况下,这是一场灾难。
.Net程序也具有支持寿命,而本机程序则没有。 Native可以在不同的操作系统上运行很多年,而无需更新。
.Net程序可能因.Net配置不当而被破坏,本机仅能继续运行,几乎不受操作系统更新的影响。
.Net程序启动缓慢并且感觉缓慢,本机启动很快并且运行很快。
.Net必须被编码为最低公分母(大多数分布式框架版本),Native将所有代码编译到应用程序中-因此请使用所需的内容。
将Delphi用于本机,而不用于C。 .Net部分基于Delphi RAD和Java后端。
我能想到的两件事。
知识产权保护。对于某人来说,对Unmanaged C应用程序进行反向工程将变得更加困难。托管.Net或Java应用程序可以很容易地反编译,而非托管C则不是这种情况。
速度。正如其他评论所提到的,C更接近于硬件,并且具有较小的内存占用量。这就是为什么大多数视频游戏继续使用C和内联汇编编写的原因。
-
比较苹果和香蕉。 C是一种多平台语言,可用于创建针对.NET环境的代码。此应用程序将像c#/ CLR或Java / JVM一样容易地反编译。然后,如果我没记错的话,GCC可以将Java编译为本机代码,因此这没有什么意义。
-
实际上,这根本没有意义,这完全取决于您使用的编译器。如果将代码编译为托管代码,那是对的。但是,如果您编译为未管理的代码,那么我的观点仍然成立。
-
与之相比,托管代码的混淆技术几乎没有什么保护作用。您是否尝试过将本机代码分解为可工作的C?相信我,这比对托管应用进行逆向工程(其中现在有任何免费工具可以做到)要困难得多。
-
我希望我可以编辑我的评论。我的意思是说现在有许多免费工具可以执行此操作。因此,如果您要编写具有更强代码保护功能的东西,绝对有优势。