【发布时间】:2023-06-12 08:45:02
【问题描述】:
如果你是一名 c++ 程序员,你会选择 Win32 API 还是 .NET 来开发 GUI 应用程序?
【问题讨论】:
-
删除了评论,因为它使问题具有主观性和争论性。没有评论,该问题与另一个问题完全相同。在评论中,问题是主观的和争论的,并且仍然与另一个问题完全相同。
如果你是一名 c++ 程序员,你会选择 Win32 API 还是 .NET 来开发 GUI 应用程序?
【问题讨论】:
我会选择Qt。它是一个跨平台的 C++ GUI 框架。
【讨论】:
Win32 是一个 API(应用程序编程接口)。 .NET 也是如此。 POSIX 也是如此。前两个将 GUI 工具包集成到主 API 中,但如果您愿意,您可以使用其他工具包,例如 Qt(由 Skildrick 建议)或 wxWindows。对于 *nix,主要的 API 是 POSIX 并且几乎都使用 X11 作为底层图形层,那么你需要一些 GUI 工具包(没有集成到 POSIX 中)。根据您想要的显示类型,OpenGL 是另一个非常好的高度可移植的 GUI 工具包,尽管它专注于高速矢量图形而不是 UI 小部件。
使用 Win32 API 的集成 GUI 工具包的一个很好的理由是 Win32 API 的许多其他部分都使用它,例如WSAAsyncSelect 和 MsgWaitForMultipleObjectsEx 是集成到 GUI 消息处理中的非 GUI 函数。一个好的包装工具包会给你足够的控制以继续使用这些工具包,但很少有人这样做,因为这种方法与非 Windows 操作系统有很大不同,而且大多数替代工具包更重视可移植性。
即使是从一开始就设计为在 Windows 上以最佳方式运行的 .NET,也不能使用来自 UI 线程的异步过程调用或可等待计时器,因为 .NET 中的任何消息处理都不使用 MsgWaitForMultipleObjects。所以你最终不得不使用多个线程和大量令人讨厌的同步代码。
但远离 MFC。它基本上是在没有编译器支持的情况下实现异常的学术练习,而不是您想要用于严肃应用程序的那种框架。大多数其他“特性”是在现代 C++ 设计被更好地理解之后添加的,但继续使用早期对异常和虚拟继承的黑客攻击开始的危险混乱风格,以保持事物一致的名义。今天有更好的选择。
【讨论】:
我会说两者都做。在 .NET 出现之前,我学到了一点 Win32 的东西。我玩过 Win32 API 本身和 MFC。这很有教育意义。我学到了很多关于 Windows 如何处理您的应用程序以及它希望您做的事情的知识。如果我现在回去学习 .NET,我很确定我会比没有任何经验的人更喜欢它。
【讨论】:
试试这本免费的书 - 我发现它非常好。它是针对 C++ 程序员的 C# 和 .net 指南,可以直接跳过常见的儿童内容。
【讨论】: