MFC和ATL之间的根本区别是什么？

假设我是only将它们用于“普通”GUI 程序（没有 COM，没有 ActiveX，没什么花哨的），我将看到 ATL 和 MFC 之间的根本区别是什么，以帮助我弄清楚使用哪一个？

我在网上做了一些搜索，但最终没有一个答案真正回答了我的问题：

• http://msdn.microsoft.com/en-us/library/bk8ytxz5(v=vs.80).aspx http://msdn.microsoft.com/en-us/library/bk8ytxz5(v=vs.80).aspx:

  • “ATL 是一种快速、简单的方法，既可以用 C++ 创建 COM 组件，又可以保持较小的占用空间。如果不需要 MFC 自动提供的所有内置功能，可以使用 ATL 创建控件。”

    并没有真正回答我的问题，因为：

    • 我不使用 COM。

    • 这是否意味着MFCisn't快速地？为什么/如何？

  • “MFC 允许您创建完整的应用程序、ActiveX 控件和活动文档。如果您已经使用 MFC 创建了控件，您可能希望继续在 MFC 中进行开发。创建新控件时，如果不需要，请考虑使用 ATL MFC 的所有内置功能。”

    也没有回答我的问题，因为：

    • 我真的不知道什么是ActiveXis首先。

    • 看来微软不鼓励使用 MFC，但我不明白为什么。

    • 到底是什么isATL不提供MFC的“内置功能”？

  • 一般来说，这并不能回答我的问题，因为它没有解释缺点以及其背后的原因。

因为直接或间接，一切似乎都链接回上一页：

• 如何决定新的 C++ 项目是使用 ATL、MFC、Win32 还是 CLR？ https://stackoverflow.com/questions/821676/how-do-i-decide-whether-to-use-atl-mfc-win32-or-clr-for-a-new-c-project

  • “在 ATL 和 MFC 之间做出选择有些困难。[[别开玩笑！]]我会推荐你​​去MSDN 页面 http://msdn.microsoft.com/en-us/library/bk8ytxz5%28VS.80%29.aspx以便在他们之间做出选择。”

    明显地，这并不能回答我的问题。 :)

• http://www.codeguru.com/forum/archive/index.php/t-64778.html http://www.codeguru.com/forum/archive/index.php/t-64778.html

• etc.

我拥有的目前观察到的（在过去几天内，同时尝试学习两者）：

• ATL is based on templates, or compile-time polymorphism.
  • ATL 方法往往是非虚拟的，并且往往返回引用。
• MFC is based on virtual methods, or run-time polymorphism.
  • MFC 方法往往是虚拟的，并且往往返回指针。

但有它们之间似乎没有任何架构差异:

• 两者都使用消息映射（BEGIN_MSG_MAP vs. BEGIN_MESSAGE_MAP...大不了）
• 两者都将 Win32 方法包装到类中
• 两者似乎都有相似的课程CWnd vs. CWindow

但是，如果除了编译时与运行时方面之外没有真正的区别，那么为什么它们都存在呢？难道其中之一就够了吗？

我在这里缺少什么？

如果你回顾一下这两个图书馆是如何起源和随时间演变的，我认为你的问题的答案主要是历史性的。

简而言之，如果您不做任何“花哨”的事情，请使用 ATL。它非常适合带有 COM 的简单用户界面。

长答案： MFC 是在 90 年代初构建的，目的是尝试这种称为 C++ 的新语言并将其应用到 Windows。它使开发社区可以使用类似于 Office 的功能，而操作系统尚不具备这些功能。

[编辑点缀：我没有在微软工作过，所以我不知道Office是否曾经是基于MFC构建的，但我认为答案是否定的。回到 Win 3.1、Win 95 时代，Office UI 团队会发明新的控件，将它们打包到库中，然后 Windows 和 MFC 团队会将包装器和 API 合并到具有可再发行 dll 的这些控件中。我猜想这些团队之间有一些协作和代码共享。最终，这些控件将进入服务包或下一个 Windows 版本中的基本操作系统。 Office 功能区延续了这种模式，它在 Office 发布后作为附加组件添加到 Windows 中，现在已成为 Windows 操作系统的一部分。]

当时该库相当原始，因为 C++ 语言和编译器都是新的，而且 Microsoft 随着 Office 的发展而不断构建它。

由于这段历史，MFC：

1. 有一个相当笨重的设计。它最初是作为 Windows API 的一个轻量级包装器，但后来不断发展。有许多小“功能”必须发明，因为编译器和语言不支持它们。没有模板，他们发明了字符串类，他们发明了列表类，他们设计了自己的运行时类型标识，等等。
2. 概括了 Office 和 Windows 20 年的发展，其中包括一大堆你可能永远不会使用的东西：单文档和多文档接口、DDE、COM、COM+、DCOM、文档链接和嵌入（这样你就可以在您的应用程序（如果您愿意的话）、ActiveX 控件（Web 对象嵌入的演变！）、结构化文档存储、序列化和版本控制、自动化（从早期的 VBA 开始），当然还有 MVC。最新版本支持 Visual Studio 样式窗口停靠和 Office 功能区。基本上，雷蒙德 20 年来的所有技术都在某个地方。实在是太大了！
3. 有大量的小陷阱、错误、解决方法、假设、对仍然存在但你永远不会使用的东西的支持，它们会导致问题。您需要非常熟悉许多类的实现以及它们如何交互才能在规模合适的项目中使用它。在调试过程中深入研究 MFC 源代码是很常见的。找到 15 年前的技术说明，其中一些指针为空导致崩溃仍然会发生。对古代文档嵌入内容初始化的假设可能会以奇怪的方式影响您的应用程序。 MFC 中不存在抽象这样的东西，您每天都需要处理它的怪癖和内部结构，它不会隐藏任何内容。不要让我开始使用类向导。

ATL 是随着 C++ 语言的发展而发明的，模板也随之出现。 ATL 展示了如何使用模板来避免 MFC 库的运行时问题：

1. 消息映射：由于它们是基于模板的，因此会检查类型，如果你搞砸了绑定函数，它就不会构建。在 MFC 中，消息映射是基于宏的，并且受运行时限制。这可能会导致奇怪的错误，消息路由到错误的窗口，如果您的函数或宏定义不正确，则会导致崩溃，或者只是因为某些东西没有正确连接而无法工作。调试起来更加困难，而且更容易在不经意间被破坏。
2. COM/自动化：与消息映射类似，COM 最初是使用宏在运行时绑定的，需要大量的错误处理并导致奇怪的问题。 ATL 使其基于模板，受编译时间限制，并且更容易处理。

[编辑补充：在创建 ATL 时，微软的技术路线图主要集中在“文档管理”上。苹果在桌面出版业务中正在扼杀他们。 Office“文档链接和嵌入”是增强 Office“文档管理”功能以在该领域竞争的主要组成部分。 COM是为应用程序集成而发明的核心技术，文档嵌入API就是基于COM的。 MFC 很难用于此用例。 ATL 是一个很好的解决方案，可以让第三方更轻松地实现这一特定技术并利用文档嵌入功能。]

这些小改进使得 ATL 在不需要 MFC 的所有 Office 功能的简单应用程序上更容易处理。具有简单的 UI 和一些 Office 自动化功能的东西。它很小，速度很快，编译时间有限，可以为您节省大量时间和头痛。 MFC 拥有庞大的类库，但这些类库可能很笨重且难以使用。

不幸的是ATL停滞不前。它有 Windows API 和 COM 支持的包装器，但它从未真正超越这一点。当网络兴起时，所有这些东西都像旧新闻一样被遗忘了。

[编辑修饰：微软意识到这个“互联网事物”将会变得很大。他们的技术路线图发生了巨大的变化，重点关注分布式事务服务器中的 Internet Explorer、Windows Server、IIS、ASP、SQL Server、COM/DCOM。因此文档链接和嵌入不再是一个高优先级。]

MFC巨大的足迹让他们无法倾倒，所以它仍然发展缓慢。模板以及其他语言和 API 增强功能已重新合并到库中。 （直到我看到这个问题，我才听说过 WTL。:)

最终，使用哪一个只是一个偏好问题。您需要的大部分功能都在基本操作系统 API 中，如果库中没有合适的包装器，您可以直接从任一库调用这些功能。

只是我的 2 美分，基于使用 MFC 多年，我现在每天都使用它。当 ATL 在几个项目上首次发布时，我已经涉足了几年。在那些日子里，这是一股新鲜空气，但从未真正去任何地方。然后网络出现了，我就忘记了它。

编辑：这个答案的寿命令人惊讶。由于它不断出现在我的堆栈溢出页面中，我想我应该为我认为缺乏的原始答案添加一些修饰。