与C#中的.NET应用程序相比,用C语言开发Win32应用程序有什么优势?

What advantages are there to developing a Win32 app in C++ over a .NET app in C#?

我学习了使用Visual C和Win32 API进行Windows编程的方法。如今,似乎大多数应用程序都是使用C#在.NET中开发的。我了解到,大多数时候本机代码和托管代码之间的性能差异不大。所以我想知道,如果我今天要开始编写一个新的桌面应用程序,除了我更熟悉C的事实以外,是否有其他原因我可能想用非托管C来编写它? .NET的?使用C和本机代码还有一些优势吗?还是在Windows平台上用.NET或多或少地替代了该方法?

我当然知道,编写底层设备驱动程序和类似程序的人不会在.NET中做到这一点。我问的是典型的不直接进行硬件调用的面向客户端的应用程序。


IMO对于小型可下载应用程序,最重要的一项是本机代码不需要.NET运行时。尽管宽带变得越来越普遍,但并不是所有人都拥有宽带。

有些人可能会失望地看到您的2 MB应用程序实际上需要另外20MB的框架下载和繁琐的安装过程才能运行。如果他们不确定一开始是否真的需要您的应用程序,则可以在尝试使用竞争产品之前将其删除。


  • 性能(某些情况下,例如图形)
  • 内存占用(如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异常被弄乱了。

  • 1,因为不需要在目标计算机上安装.NET软件包。这仍然是一个大问题。

    当所有计算机都具有mono或NET时,没什么大不了的。


    如果您可以负担得起对堆栈的依赖,请使用.NET
    现代,优雅,强大,因此可以更快地开发。

    但是要意识到,您已将应用程序链接到它-语言和框架,如果您预见到将来可能希望摆脱这种情况的情况,那么请三思而后行。

    Win32既旧又笨拙,但是它几乎可以在没有附加依赖项的任何Windows版本上运行,并且您的代码可以是纯净的,可移植的C / C。


    内存占用量。但是,除非您为严重的机器内存问题而开发,否则对于大多数应用程序来说,这实际上不是问题。


    .Net程序也具有支持寿命,而本机程序则没有。 Native可以在不同的操作系统上运行很多年,而无需更新。

    .Net程序可能因.Net配置不当而被破坏,本机仅能继续运行,几乎不受操作系统更新的影响。

    .Net程序启动缓慢并且感觉缓慢,本机启动很快并且运行很快。

    .Net必须被编码为最低公分母(大多数分布式框架版本),Native将所有代码编译到应用程序中-因此请使用所需的内容。

    将Delphi用于本机,而不用于C。 .Net部分基于Delphi RAD和Java后端。


    我能想到的两件事。

  • 知识产权保护。对于某人来说,对Unmanaged C应用程序进行反向工程将变得更加困难。托管.Net或Java应用程序可以很容易地反编译,而非托管C则不是这种情况。

  • 速度。正如其他评论所提到的,C更接近于硬件,并且具有较小的内存占用量。这就是为什么大多数视频游戏继续使用C和内联汇编编写的原因。