c# - 用 C++ 开发 Win32 应用程序比用 C# 开发 .NET 应用程序有什么优势？

Question

我使用 Visual C++ 和 Win32 API 学习了 Windows 编程。如今，似乎大多数应用程序都是使用 C# 在 .NET 中开发的。我知道大多数时候本机代码和托管代码之间没有太大的性能差异。所以我想知道，如果我今天要开始编写一个新的桌面应用程序，是否有任何理由（除了我更熟悉 C++ 的事实），我可能想用非托管 C++ 编写它.NET 的？使用 C++ 和本机代码还有一些优势吗？或者这种方法在 Windows 平台上是否或多或少地被 .NET 取代了？

当然，我知道编写低级设备驱动程序和类似程序的人不会在 .NET 中这样做。我问的是典型的不直接硬件调用的面向客户端的应用程序。

Answer 1

IMO 对小型可下载应用程序最重要的一项是本机代码不需要 .NET 运行时。虽然宽带变得越来越普遍，但并不是几乎每个人都拥有它。

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

Answer 2

• 性能（某些情况，例如图形）
• 内存占用（正如曼库索所说）
• 使用现有图书馆
• 不需要运行时
• 更精细的控制

列举几个。

但是，您可能还想从相反的角度看待问题，以公平地评估使用哪种语言。

此外，您可以使用 C++/CLI 来合并本机代码和 .net 代码。

Answer 3

如果您的应用程序需要能够在不安装的情况下运行（即，如果您不能或不应该执行诸如安装 .NET 框架之类的操作），则不能指望 .NET 在 Windows 机器上（Vista 之前）。许多实用程序应用程序都属于这一类。

Answer 4

我建议用托管代码编写每个桌面应用程序。.NET/C# 是一个很好的平台。

我的理由：

1. 性能损失可以忽略不计。如果您不相信我的话，请在 Google 上进行基准测试。更重要的是代码本身。您可以在 C++ 或 .NET/C# 中编写 O(n^m) 算法。如今，JIT 引擎非常成熟。
2. 在单元测试、模拟和重构方面，非托管 C++ 存在重大缺陷。这非常麻烦且不灵活。反射允许托管代码使此类事情变得非常方便。
3. 部署是一个小问题。但是，创建一个检查必要的 .NET 前提条件并自动安装它们的设置是不费吹灰之力的。
4. 编译更快，没有链接器！当您编辑代码时，它甚至会在后台发生。
5. .NET库支持比 STL、MFC 和 boost 更好、更干净。
6. 没有头文件和宏。他们只是容易出错。
7. 安全！再见缓冲区溢出，错误的指针，未初始化的变量......
8. 例外。清除 .NET 中的异常层次结构。C++ 异常被搞砸了。

Answer 5

内存占用。但是，除非您正在为内存严重受损的机器进行开发，否则对于大多数应用程序来说，这确实不应该成为问题。

Answer 6

如果您负担得起对堆栈的依赖，请选择 .NET Modern、优雅、强大，因此开发速度更快。

但是要意识到你将你的应用程序链接到它 - 到语言和框架，如果你预见到你可能想要逃避这种情况的未来，那么最好三思而后行。

Win32 既旧又笨重，但它几乎可以在任何 Windows 版本上运行，无需额外依赖，而且您的代码可以是简单、可移植的 C/C++。

Answer 7

+1 不需要在目标机器上安装 .NET 包/安装。这仍然是一个大问题。

当所有机器都有单声道或 NET 时，这没什么大不了的。

Answer 8

我能想到的两件事。

1. 知识产权保护。对非托管 C++ 应用程序进行逆向工程要困难得多。托管的 .Net 或 Java 应用程序可以很容易地反编译，而非托管 C++ 则不然。

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

Answer 9

.Net 程序也有一个支持生命周期，而原生程序则没有。Native 将在不同的操作系统上运行多年，无需更新。

.Net 程序可能会被糟糕的 .Net 配置所破坏，本机只是继续运行，几乎不受操作系统更新的影响。

.Net 程序启动慢，感觉迟钝，native 启动快，运行快。

.Net 必须针对最低公分母（大多数分布式框架版本）进行编码，Native 将所有代码编译到应用程序中 - 所以使用你想要的。

将 Delphi 用于 Native，而不是 C++。.Net 部分基于 Delphi RAD 和 Java 后端。