我刚刚开始我的第一个C++项目。我正在使用Visual Studio 2008。它是一个单一窗体的Windows应用程序，用于访问几个数据库并启动WebSphere MQ事务。我基本上理解ATL，MFC，Win32（我实际上对此有点朦胧）和CLR之间的差异，但是我对如何选择我感到不知所措。如何决定是否将ATL，MFC，Win32或CLR用于新的C++项目？
是否有一个或多个这些只是为了向后兼容？
是CLR a bad idea？
任何建议表示赞赏。
编辑： 我选择C++这个项目的原因，我没去成在后，这是不完全的技术。所以，假设 C++是唯一的/最好的选择，我应该选择哪一个？
这取决于您的需求。
使用CLR将为您提供最具表现力的库集合（整个.NET框架），代价是限制您的可执行文件需要在运行时安装.NET框架，并限制您Windows平台（但是，所有4种上市技术都只是Windows，所以平台限制可能是最麻烦的）。
但是，CLR要求您使用C++语言的C++/CLI扩展，所以您将本质上需要学习一些额外的语言功能才能使用它。这样做会给你许多额外的东西，比如访问.net库，完全垃圾回收等。
ATL & MFC在决定之间有点棘手。我会推荐你MSDN's page for choosing为了决定他们之间。 ATL/MFC的好处在于你不需要.NET框架，只需要安装部署的VC/MFC运行时。
使用Win32直接提供最小的可执行文件，具有最少的依赖关系，但是需要编写更多的工作。你有最少量的帮助程序库，所以你正在编写更多的代码。
我会很好奇你为什么要用C++来做这件事。根据您的简要描述，C＃听起来像是一个更合适的选择。
只是想详细说明一下，看看你给出的描述C++ CLR的链接。评分最高的答案笔记（准确地说，在我看来）C++适用于“内核，游戏，高性能和服务器应用程序” - 其中没有一个似乎描述你在做什么。
将会支持MFC，ATL等，因为您可以在将来版本的Visual Studio上编译您的应用程序，并在未来版本的Windows上运行它们。但是他们并不支持这样的意思，即在CLR和C＃中没有太多新的开发发生在API或语言中。
Win32是原始的裸机方式。这很乏味，很难使用，并且需要记住很多细节，否则事情会以相对神秘的方式失败。
MFC构建于Win32上，为您提供构建应用程序的面向对象方法。它不是Win32的替代品，而是一个增强功能 - 它为你做了很多艰苦的工作。System.Windows.Forms（这是我假设你指的是CLR）是完全不同的，但与MFC的基本结构有很大的相似之处。这是迄今为止最容易使用的，但需要.NET框架，这可能会或可能不会成为您的情况的障碍。我的推荐：如果你需要避免.NET，那么使用MFC，否则使用.NET（事实上，在那种情况下，我会使用C＃，因为它更容易处理）。
至于C++去，我会使用WTL。这是轻而易举的，你将会有很少的（如果有的话）依赖关系，使其易于运输和安装。当我的应用程序包含可在大多数Windows版本上运行的单个EXE时，我感到非常满意，但这可能不是您的问题。
如果你选择去.NET，那么C＃几乎肯定是要走的路。
更WTL这里：
没有什么错CLR。和其他人一样，我建议使用C＃，但是因为你有理由坚持使用C++，那么使用.NET框架比使用ATL/MFC搞乱几千倍，如果你不熟悉它们（IMO）。
值得一提的是，如果你使用C++/CLR，那么你根本就没有真正使用C++。 C++/CLR像C＃一样编译为CIL。我从来没有使用过它，但我相信它的目的是允许您编译遗留代码并使其可以轻松地用于新的.NET代码，而不是允许新的代码与旧的C++可执行文件一起工作。还有其他从.NET调用本地代码的方法，或许您应该探索一下。
好问题。它是一个大型项目的一部分，其中包含一些其他因为遗留和供应商原因而必须使用C++的部分。这部分没有*是用C++编写的，但是由于还有其他部分可以做，而且由于这部分相对较小，所以我打算用同一种语言来完成。 – 2009-05-04 19:56:20
如果您喜欢使用C＃，但希望/需要使用C++，则C++/CLI（/ clr）可以非常接近C＃。主要区别在于一些小的语法，并试图避免使用标准C++而不是CLI调用。真的没有理由避免它。 – 2009-05-04 19:59:25
这不一定是一个糟糕的思考过程。但是我仍然认为你最好打赌是把C＃和P/Invoke放到你现有的库中。如果你已经*了一个MFC大师，这只是你项目的一个小小的补充，那么是的，它可能会继续使用C++。尽管即使在这种情况下，它也可能是一个很好的机会，可以利用.NET框架挖掘一些“练习时间” – Clyde 2009-05-04 19:59:38