【问题标题】:How do I decide whether to use ATL, MFC, Win32 or CLR for a new C++ project?我如何决定是否为新的 C++ 项目使用 ATL、MFC、Win32 或 CLR?
【发布时间】:2010-10-23 17:29:15
【问题描述】:

我刚刚开始我的第一个 C++ 项目。我正在使用Visual Studio 2008。它是一个单一形式的 Windows 应用程序,它访问几个数据库并启动一个 WebSphere MQ 事务。我基本上了解ATL、MFC、Win32(实际上我对那个有点模糊)和CLR之间的区别,但我不知道应该如何选择。

其中一个或多个只是为了向后兼容吗?

CLR是a bad idea吗?

任何建议表示赞赏。

编辑: 我为这个项目选择了 C++ 的原因是我在帖子中没有提到的,这并不完全是技术性的。那么,假设 C++ 是唯一/最好的选择,我应该选择哪个?

【问题讨论】:

    标签: c++ winapi mfc clr atl


    【解决方案1】:

    这取决于您的需求。

    使用 CLR 将为您提供最具表现力的库集(整个 .NET 框架),但代价是将您的可执行文件限制为要求在运行时安装 .NET 框架,以及将您限制在Windows 平台(但是,所有列出的 4 种技术都只是 Windows,因此平台限制可能是最不麻烦的)。

    但是,CLR 要求您使用 C++/CLI 对 C++ 语言的扩展,因此本质上,您需要学习一些额外的语言功能才能使用它。这样做可以为您提供许多“额外功能”,例如访问 .net 库、完整的垃圾回收等。

    在 ATL 和 MFC 之间做出决定有点棘手。我会将您推荐给MSDN's page for choosing,以便在它们之间做出决定。 ATL/MFC 的好处是您不需要 .NET 框架,只需安装 VC/MFC 运行时即可进行部署。

    直接使用Win32提供最小的可执行文件,具有最少的依赖关系,但要编写更多的工作。您的帮助程序库数量最少,因此您编写的代码更多。

    【讨论】:

      【解决方案2】:

      Win32 是一种原始的、裸机的方式。它乏味、难以使用,并且有很多小细节需要记住,否则事情会以相对神秘的方式失败。

      MFC 建立在 Win32 之上,为您提供一种面向对象的方式来构建您的应用程序。它不是 Win32 的替代品,而是一种增强功能 - 它为您完成了很多艰苦的工作。

      System.Windows.Forms(我假设你的意思是 CLR)完全不同,但与 MFC 的基本结构有很大的相似之处。到目前为止,它是最容易使用的,但需要 .NET 框架,这在您的情况下可能会或可能不会成为障碍。

      我的建议:如果您需要避免使用 .NET,则使用 MFC,否则使用 .NET(实际上,在这种情况下,我会使用 C#,因为它更容易使用)。

      【讨论】:

      • 此评论是否仍然有效?
      • 对于 Visual Studio 2008,可能 - 现在已经有十年历史了。现在,对于 Windows,使用 WPF 会好得多。
      【解决方案3】:

      就 C++ 而言,我会使用 WTL。它是轻量级的,您将几乎没有(如果有的话)依赖项,使其易于运输和安装。当我的应用程序包含一个可在大多数 Windows 版本上运行的 EXE 时,我觉得非常令人满意,但这对您来说可能不是问题。

      如果您选择改用 .NET,那么 C# 几乎可以肯定是要走的路。

      这里有更多关于 WTL 的内容:

      http://www.codeproject.com/KB/wtl/wtl4mfc1.aspx

      【讨论】:

      【解决方案4】:

      我很好奇你为什么要用 C++ 来做这件事。根据您的简短描述,C# 听起来是一个更合适的选择。

      为了详细说明,请查看您提供的描述 C++ CLR 的链接。评分最高的答案指出(准确地说,在我看来)C++ 适用于“内核、游戏、高性能和服务器应用程序”——似乎没有一个能描述你在做什么。

      将支持 MFC、ATL 等,是的,您将能够在未来版本的 Visual Studio 上编译您的应用程序并在未来版本的 Windows 上运行它们。但从某种意义上说,它们不受支持,因为 API 或语言中没有像 CLR 和 C# 中那样进行很多新的开发。

      【讨论】:

      • 好问题。它是一个更大项目的一部分,其中包括一些其他部分,由于遗留和供应商相关的原因,这些部分必须在 C++ 中。这部分必须使用 C++,但因为还有其他部分可以使用,而且这部分相对较小,所以我打算用同一种语言来完成。
      • C++/CLI (/clr) 可以非常接近 C#,如果你喜欢在 C# 中工作,但想要/需要使用 C++。主要区别在于一些小的语法问题,并尽量避免使用标准 C++ 而不是 CLI 调用。真的没有理由避免它。
      • 这不一定是一个糟糕的思考过程。但是我仍然认为您最好的选择是使用 C#,并将 P/Invoke 放入您现有的库中。如果您已经是 MFC 大师,而这只是对您项目的一个小补充,那么是的,继续使用 C++ 可能是有意义的。尽管即使在这种情况下,它也可能是一个很好的机会,可以利用 .NET 框架开辟一些“练习时间”
      • @Clyde:我的经验是,C++ 互操作层比尝试 P/Invoke 更易于使用,并且更具表现力。如果您正在使用其他 C++ 代码,我个人使用 C++/CLI 来完成所有互操作。如果 GUI 层很大,我可能会使用 C# - 如果它是一个小项目,我可能会将整个东西保留在 C++/CLI 中。 C++ 与 .NET 框架配合得很好 - 与 C# 一样(C++ 中有一些更难的事情,但在使用 .NET 时,C++ 中的一些事情比 C# 容易得多)。
      【解决方案5】:

      CLR 没有任何问题。像这里的其他人一样,我建议使用 C#,但是由于您有理由坚持使用 C++,因此如果您还不熟悉 ATL/MFC (IMO),那么使用 .NET 框架要比使用 ATL/MFC 容易数千倍。

      值得一提的是,如果您使用的是 C++/CLR,那么您根本就没有真正使用 C++。 C++/CLR 像 C# 一样编译成 CIL。我自己从未使用过它,但我相信它的目的是允许您编译遗留代码并使其易于用于新的 .NET 代码,而不是允许新代码与旧的 C++ 可执行文件一起使用。还有其他从 .NET 调用本机代码的方法,或许您应该探索一下。

      【讨论】:

      • 如果我必须使用 .NET 库,我宁愿用 C# 编写
      【解决方案6】:

      这个问题的现代(2021 年)答案似乎是使用 C++/WinRT 而不是 C++/CLR(或 C++/CLI 或 C++/CX...天哪,微软):

      https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/intro-to-using-cpp-with-winrt

      C++/WinRT 是用于 Windows 运行时 (WinRT) API 的完全标准的现代 C++17 语言投影,实现为基于头文件的库,旨在为您提供对现代 Windows API 的一流访问.借助 C++/WinRT,您可以使用任何符合标准的 C++17 编译器来创作和使用 Windows 运行时 API。

      ...

      C++/WinRT 是微软推荐的 C++/CX 语言投影的替代品

      它基本上是标准的 C++,但 UI 是用 XAML 定义的。

      尽管如此,与其他答案一样,使用 C# 似乎确实是微软最喜欢的方法。无论如何,C++/WinRT 看起来真的几乎是 C#。

      【讨论】:

        猜你喜欢
        • 2011-02-08
        • 1970-01-01
        • 2013-03-06
        • 1970-01-01
        • 2012-09-05
        • 2013-06-21
        • 2014-12-26
        • 2023-03-14
        • 2010-09-20
        相关资源
        最近更新 更多