我刚开始我的第一个C++项目。我正在使用Visual Studio 2008。这是一个单窗体Windows应用程序，它访问了一些数据库并启动了WebSphere MQ交易。我基本上了解了ATL、MFC、Win32（实际上还有点模糊）和CLR之间的区别，但我不知道该如何选择。
其中一个或多个只是为向后兼容而存在吗？
任何建议都会受到赞赏。
编辑： 我选择了C++用于此项目，但原因我在帖子中没有详细说明，这些原因并非完全技术性的。所以，假设C++是唯一/最佳选择，我应该选择哪个呢？
6个回答
72
这要看你的需求。
使用CLR会为您提供最丰富的库（整个.NET框架），但代价是限制了您的可执行文件在运行时需要安装.NET框架，并且限制您只能在Windows平台上运行（不过，所有列出的4种技术都只适用于Windows，因此平台限制可能是最不麻烦的）。
然而，CLR要求您使用C++/CLI扩展C++语言，因此您需要学习一些额外的语言特性才能使用它。这样做可以为您提供许多“额外”的功能，例如访问.net库、完整的垃圾收集等。
在ATL和MFC之间进行选择有些棘手。我建议您参考MSDN的选择页面来决定。 ATL/MFC的好处是，您不需要.NET框架，只需要安装VC/MFC运行库即可部署。
直接使用Win32提供了最小的可执行文件，最少的依赖关系，但编写工作量更大。您拥有最少的辅助库，因此需要编写更多的代码。
- Reed Copsey
28
Win32是一种原始的、裸机的实现方式。它很繁琐，难以使用，有很多细节需要记住，否则事情会以相对神秘的方式失败。
MFC在Win32的基础上提供了一种面向对象的构建应用程序的方式。它不是Win32的替代品，而是一种增强——它为你做了许多艰苦的工作。
System.Windows.Forms（我想你指的是CLR）完全不同，但与MFC的基本结构有很大的相似之处。它是迄今为止最容易使用的，但需要.NET框架，这可能或可能不是一个妨碍。
我的建议：如果你需要避免.NET，那么使用MFC，否则使用.NET（事实上，在这种情况下，我会使用C#，因为它更容易使用）。
- Chris Walton
2
1这个注释还有效吗？ - Janus Troelsen
1对于 Visual Studio 2008，可能 - 虽然那已经是十年前的事了。如今，对于 Windows 平台，使用 WPF 会更好。 - Chris Walton
15
就C++而言，我会使用WTL。它是轻量级的，你几乎不需要依赖项（如果有的话也很少），使得它易于分发和安装。当我的应用程序只包含一个 EXE 文件并可以在大多数 Windows 版本上运行时，我觉得非常满意，但这可能不是你关心的问题。
如果你选择使用 .NET，则几乎肯定应该使用 C#。
这里有更多关于 WTL 的信息：
- Rob
2
1@JanusTroelsen 我会的！最新版本发布于2020年3月18日 - 版本10.1077！https://sourceforge.net/projects/wtl/files/WTL%2010/WTL%2010.0.10077/ - fabspro
8
我非常好奇为什么您要用C++来做这件事。根据您的简要描述，C#似乎更加合适。
再详细解释一下，看看您提供的描述C++ CLR的链接。排名第一的答案指出（在我看来非常准确），C++适用于“内核、游戏、高性能和服务器应用程序”，这些都不太像您正在做的事情。
MFC、ATL等将得到支持，也就是说，您将能够在未来版本的Visual Studio上编译您的应用程序，并在未来版本的Windows上运行它们。但是从API或语言方面来看，与CLR和C#中正在进行的大量新开发相比，它们并没有得到很好的支持。
再详细解释一下，看看您提供的描述C++ CLR的链接。排名第一的答案指出（在我看来非常准确），C++适用于“内核、游戏、高性能和服务器应用程序”，这些都不太像您正在做的事情。
MFC、ATL等将得到支持，也就是说，您将能够在未来版本的Visual Studio上编译您的应用程序，并在未来版本的Windows上运行它们。但是从API或语言方面来看，与CLR和C#中正在进行的大量新开发相比，它们并没有得到很好的支持。
- Clyde
4
好问题。这是一个更大项目的一部分，其中包括其他一些必须使用C++的部分，原因是遗留和供应商相关。虽然这部分不一定非得用C++编写，但由于还有其他部分需要使用C++，而且这部分相对较小，所以我计划全部使用同一种语言来完成。 - John M Gant
如果你喜欢使用 C#，但需要使用 C++，那么 C++/CLI（/clr）非常接近 C#。主要的区别是一些微小的语法问题，并尝试避免使用标准 C++而不是 CLI 调用。实际上没有理由避免使用它。 - Reed Copsey
这并不一定是一个坏的思路。然而，我仍然认为你最好选择C#，并使用P/Invoke调用现有的库。如果你已经是MFC大师，并且这只是你项目的一个小部分，那么继续使用C++可能是有意义的。尽管即使在这种情况下，它也可能是一个很好的机会来刻意练习.NET框架。 - Clyde
1@Clyde：我的经验是，与P/Invoke相比，C ++互操作层更易于使用，更具表现力。 如果您正在使用其他C ++代码，则我个人使用C ++ / CLI进行所有互操作。 如果GUI图层很大，我可能会使用C＃ - 如果是一个小项目，我可能只会将整个项目保留在C ++ / CLI中。 C ++非常适合与.NET框架一起使用 - 与C#一样好（在处理.NET时，有一些东西比C＃更难，但有些东西在C ++中比在C＃中更容易）。 - Reed Copsey
4
CLR没有问题。像其他人一样，我建议使用C#，但如果您有坚持使用C++的理由，则使用.NET框架比与ATL/MFC搞在一起要容易几千倍（依我之见）。
值得一提的是，如果您正在使用C++/CLR，则实际上并未真正使用C++。C++/CLR编译成CIL，就像C#一样。我自己从未使用过它，但我相信它的目的是允许您编译遗留代码，并使其轻松地可用于新的.NET代码，而不是允许新代码与旧的C++可执行文件一起工作。还有其他调用本机代码的.NET方法，也许您应该探索一下。
- Patrick
1
如果我必须使用.NET库，我宁愿用C#编写。 - Thanh Nguyen
0
2021年的现代答案似乎是使用C++/WinRT而不是C++/CLR（或C++/CLI或C++/CX...天哪，微软）：
https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/intro-to-using-cpp-with-winrt
C++/WinRT是一个完全标准的现代C++17语言投影，用于Windows Runtime（WinRT）API，实现为基于头文件的库，并旨在为您提供对现代Windows API的一流访问。使用C++/WinRT，您可以使用任何符合标准的C++17编译器编写和使用Windows Runtime API。...
C++/WinRT是微软推荐的C++/CX语言投影的替代品。
基本上它是标准的C++，但UI是用XAML定义的。
尽管如其他答案所述，似乎使用C#才是微软最喜欢的方法。C++/WinRT看起来几乎就像C#一样。
- MHebes
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接