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

What's the fundamental difference between MFC and ATL?

提问by user541686

Assuming I am onlyusing them for "normal" GUI programs (no COM, no ActiveX, nothing fancy), what is the fundamental difference I will see between ATL and MFC, to help me figure out which one to use?

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

---

---

I've done some searches on the web, but ultimately none of the answers really answered my question:

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

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

  • "ATL is a fast, easy way to both create a COM component in C++ and maintain a small footprint. Use ATL to create a control if you don't need all of the built-in functionality that MFC automatically provides."

    Doesn't really answer my question, because:

    • I'm not working with COM.

    • Does this imply MFC isn'tfast? Why/how?

  • "MFC allows you to create full applications, ActiveX controls, and active documents. If you have already created a control with MFC, you may want to continue development in MFC. When creating a new control, consider using ATL if you don't need all of MFC's built-in functionality."

    Also doesn't answer my question, because:

    • I don't really even know what ActiveX isin the first place.

    • It looks as though Microsoft is discouraging the use of MFC, but I can't figure out why.

    • What exactly isMFC's "built-in functionality" that ATL doesn't provide?

  • In general, this doesn't answer my question because it doesn't explain the downsidesand the reasons behind them.

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

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

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

    • 我不使用 COM。

    • 这是否意味着MFC是不是快吗？为什么/如何？

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

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

    • 我什至不知道 ActiveX是什么。

    • 看起来微软不鼓励使用 MFC，但我不知道为什么。

    • ATL 没有提供的 MFC 的“内置功能”究竟是什么？

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

because directly or indirectly, everything seems to link back to the previous page:

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

• How do I decide whether to use ATL, MFC, Win32 or CLR for a new C++ project?

  • "ATL & MFC are somewhat trickier to decide between.[[No kidding!]] I'd refer you to MSDN's pagefor choosing in order to decide between them."

    Obviously, this doesn't answer my question. :)

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

• etc.

• 我如何决定对新的 C++ 项目使用 ATL、MFC、Win32 还是 CLR？

  • “在 ATL 和 MFC 之间做出决定有点棘手。[[不开玩笑！]]我建议您参考MSDN 的页面进行选择，以便在它们之间做出决定。”

    显然，这不能回答我的问题。:)

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

• 等等。

What I have currently observed(within the last couple of days, while trying to learn both):

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

• ATL is based on templates, or compile-time polymorphism.
  • ATL methods tend to be non-virtual, and tend to return references.
• MFC is based on virtual methods, or run-time polymorphism.
  • MFC methods tend to be virtual, and tend to return pointers.

• ATL 基于模板或编译时多态性。
  • ATL 方法往往是非虚拟的，并且倾向于返回引用。
• MFC 基于虚拟方法或运行时多态性。
  • MFC 方法往往是虚拟的，并且倾向于返回指针。

But there doesn't seem to be any architectural difference between them:

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

• Both use message maps (BEGIN_MSG_MAPvs. BEGIN_MESSAGE_MAP... big deal)
• Both wrap Win32 methods into classes
• Both seem to have similar classes CWndvs. CWindow

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

But then, if there's no real difference except for the compile-time vs. run-time aspect, then why do both of them exist? Shouldn't one of them be enough?

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

What am I missing here?

我在这里缺少什么？

回答by Jay

I think the answer to your question is mostly historical, if you look back at how the two libraries originated and evolved through time.

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

The short answer is, if you are not doing anything "fancy", use ATL. It's great for simple user interfaces with COM thrown in.

简短的回答是，如果您没有做任何“花哨”的事情，请使用 ATL。它非常适合带有 COM 的简单用户界面。

The long answer: MFC was built in the early 90s to try out this new language called C++ and apply it to Windows. It made Office like features available to the development community when the OS didn't have them yet.

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

[Edit embellishment: I did not work at Microsoft, so I don't know if Office was ever built on MFC, but I think the answer is no. Back in Win 3.1, Win 95 days, Office UI team would invent new controls, package them up in libraries, then the Windows and MFC teams would incorporate wrappers and API to those controls with redistributable dlls. I would guess there was a bit of collaboration and code sharing between those teams. Eventually those controls would make it into the base operating system in service packs or the next Windows version. This pattern continued with the Office Ribbon which was added into Windows as an add-on component well after Office shipped, and is now part of the Windows OS.]

【编辑点缀：我没在微软工作，所以不知道Office有没有建立在MFC上，但我认为答案是否定的。回到 Win 3.1，Win 95 days，Office UI 团队会发明新的控件，将它们打包到库中，然后 Windows 和 MFC 团队会将包装器和 API 合并到那些带有可再分发 dll 的控件中。我猜想这些团队之间有一些协作和代码共享。最终，这些控件将使其成为 Service Pack 或下一个 Windows 版本中的基本操作系统。这种模式延续到 Office Ribbon，它在 Office 发布后作为附加组件添加到 Windows 中，现在是 Windows 操作系统的一部分。]

At that time the library was quite primitive, both because of the C++ language and compiler being new, and Microsoft building it up over time as Office evolved.

那个时候这个库还很原始，因为 C++ 语言和编译器都是新的，而且微软随着 Office 的发展而建立它。

Because of this history, MFC:

由于这段历史，MFC：

1. Has a fairly clunky design. It started as a light wrapper around the Windows API, but grew. There are a bunch of little 'features' that had to be invented because the compiler and language just didn't support them. There were no templates, they invented a string class, they invented list classes, they designed their own run time type identification, etc.
2. Encapsulates 20 years of Office and Windows evolution, which includes a whole crap load of stuff you will probably never use: Single and Multiple Document interfaces, DDE, COM, COM+, DCOM, Document Linking and Embedding (so you can embed a word document in your app if you wanted to), ActiveX controls (evolution of object embedding for the web!), Structured Document Storage, Serialization and Versioning, Automation (from early VBA years), and of course MVC. The latest versions have support for Visual Studio style window docking, and the Office ribbon. Basically every technology out of Redmond in 20 years is in there somewhere. It's just HUGE!
3. Has a ton of little gotchas, bugs, workarounds, assumptions, support for things that are still there that you will never use, and they cause problems. You need to be intimately familiar with the implementation of many classes and how they interact to use it on a decent size project. Delving into MFC source code during debugging is common. Finding a 15 year old tech note on some pointer being null causing a crash still happens. Assumptions on initialization of ancient document embedding stuff can affect your application in weird ways. There's no such thing as abstraction in MFC, you need to work with it's quirks and internals daily, it doesn't hide anything. And don't get me started on the class wizard.

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

ATL was invented as the C++ language evolved, and templates arrived. ATL was a showcase of how to use templates to avoid the run-time problems of the MFC library:

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

1. Message maps: Since they are template based, types are checked, and if you screw up the bound function, it doesn't build. In MFC message maps are macro based, and run-time bound. This can cause odd bugs, message routed to the wrong window, a crash if you have function or macro defined incorrectly, or just simply not work because something isn't hooked up right. Much more difficult to debug, and easier to break without noticing.
2. COM/Automation: Similar to message maps, COM was originally run-time bound using Macros, requiring lots of error handing and causing odd problems. ATL made it template based, compile time bound, and much, much easier to deal with.

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

[Edit Embellishment: At the time ATL was created, Microsoft's technical road map was mainly focused on 'Document Management'. Apple was killing them in the desktop publishing business. Office 'Document Linking and Embedding' was a main component to enhancing the 'Document Management' features of Office to compete in this space. COM was a core technology invented for application integration, and Document Embedding API's were based on COM. MFC was difficult to use for this use case. ATL was a good solution to make this particular technology easier for 3rd party's to implement COM and utilize document embedding features.]

【编辑点缀：在ATL创建的时候，微软的技术路线图主要集中在'文档管理'上。苹果在桌面出版业务中扼杀了他们。Office 的“文档链接和嵌入”是增强 Office 的“文档管理”功能以在该领域竞争的主要组成部分。COM 是为应用程序集成而发明的核心技术，文档嵌入 API 是基于 COM 的。MFC 很难用于这个用例。ATL 是一个很好的解决方案，可以使这种特殊技术更容易让 3rd 方实现 COM 并利用文档嵌入功能。]

These little improvements make ATL hugely easier to deal with on a simple application that doesn't need all the office like features of MFC. Something with a simple UI and some Office automation thrown in. It's small, it's fast, it's compile time bound saving you much time and headache. MFC has a huge library of classes that can be clunky, and difficult to work with.

这些小改进使 ATL 在一个简单的应用程序上更容易处理，它不需要像 MFC 那样的所有 office 功能。一些带有简单 UI 和一些 Office 自动化的东西。它很小，很快，编译时间有限，为您节省了很多时间和麻烦。MFC 有一个庞大的类库，这些类库可能很笨重，而且难以使用。

Unfortunately ATL stagnated. It had wrappers for the windows API and COM support, and then it never really went beyond that. When the Web took off, all this stuff was sort of forgotten as old news.

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

[Edit Embellishment: Microsoft realized that this 'Internet Thing' was going to be big. Their technical road map changed drastically to focus on Internet Explorer, Windows Server, IIS, ASP, SQL Server, COM/DCOM in Distributed Transaction Server. So the Document Linking and Embedding was no longer a high priority.]

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

The huge footprint of MFC made it impossible for them to dump, so it still evolves slowly. Templates have been incorporated back into the library, as well as other language and API enhancements. (I had not heard of WTL until I saw this question. :)

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

Ultimately, which one to use is simply a matter of preference. The majority of the features you need are in the base OS API, which you can call directly from either library, if there is no suitable wrapper in the library.

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

Just my 2 cents based on using MFC for many years, and I use it now daily. I dabbled in ATL when it was first released on a few projects for a couple of years. It was a breath of fresh air in those days, but never really went anywhere. And then the Web came along and I forgot all about it.

基于使用 MFC 多年，我只花了 2 美分，我现在每天都在使用它。当 ATL 在几个项目中首次发布时，我涉足了几年。在那个年代，这是一股清新的空气，但从来没有真正去过任何地方。然后网络出现了，我忘记了一切。

---

---

Edit: This answer has surprising longevity. Since it keeps popping up in my stack overflow page, I thought I'd add some embellishment to the original answer I thought was lacking.

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

回答by Merlyn Morgan-Graham

I have been told by many people who have used both that their programming experience was less painful with ATL than with MFC. Your compiled executable will also be much smaller with ATL.

许多使用过这两种方法的人告诉我，他们的编程经验使用 ATL 不如使用 MFC。使用 ATL 编译后的可执行文件也会小得多。

I recommend you take a look at WTL, as it builds upon ATL.

我建议你看看 WTL，因为它建立在 ATL 之上。

What is that "extra functionality" they keep mentioning? Do I need it?

他们一直提到的“额外功能”是什么？我需要吗？

If you define your requirements, it might be easier to answer if you can avoid using MFC. Unfortunately "nothing fancy" isn't exclusive enough. Being inclusive as to which features you intend to use might be more helpful (which controls, which frameworks/technologies/existing libraries you want to use, etc).

如果您定义了您的要求，如果您可以避免使用 MFC，那么回答起来可能会更容易。不幸的是，“没什么特别的”还不够排他性。包含您打算使用哪些功能可能会更有帮助（哪些控件，您要使用哪些框架/技术/现有库等）。

But here's an article that describes some features in MFC that aren't directly supported by WTL/ATL.

但是这里有一篇文章描述了 MFC 中 WTL/ATL 不直接支持的一些功能。

MFC also has evolved to the point it supports a great many desirable features, such as MAPI, support for the other Windows logo requirements, sockets, documents (if you like and/or use that pattern), and compound document files. WTL has its share of cool features, but MFC is the clear feature champ. Both environments support framed main window architectures (frame window with separate view window), SDI and MDI applications, split windows, dialog-based applications, and various COM-based classes for COM support.

MFC 也已经发展到支持许多理想的功能，例如 MAPI、对其他 Windows 徽标要求的支持、套接字、文档（如果您喜欢和/或使用该模式）和复合文档文件。WTL 有很多很酷的特性，但 MFC 是明显的特性冠军。这两种环境都支持框架主窗口体系结构（框架窗口具有单独的视图窗口）、SDI 和 MDI 应用程序、拆分窗口、基于对话框的应用程序和各种基于 COM 的 COM 支持类。

回答by Alexandre C.

ATL is a set of classes meant to simplify the implementation of COM objects.

ATL 是一组旨在简化 COM 对象实现的类。

You can use it without MFC. At my job, we use ATL to expose COM interfaces to computational code. There is no GUI involved, it is for us to be able to call this computational code from eg. Excel VBA.

您可以在没有 MFC 的情况下使用它。在我的工作中，我们使用 ATL 将 COM 接口暴露给计算代码。不涉及GUI，我们可以从例如调用这个计算代码。Excel VBA。

Look at some COM guide/tutorial to see what it abstracts.

查看一些 COM 指南/教程，看看它抽象了什么。

MFC is just a set of GUI wrapper classes to the Win32 API. Look at some Win32 API tutorial to see what it abstracts.

MFC 只是 Win32 API 的一组 GUI 包装类。看看一些 Win32 API 教程，看看它抽象了什么。