MFC和ATL的根本区别是什么？ [英] What's the fundamental difference between MFC and ATL?

问题描述

假设我只是将它们用于普通GUI程序（没有COM，没有ActiveX，没有什么奇怪），我将看到ATL和MFC之间的根本区别，帮助我找出使用哪一个？

---

最终没有答案真的回答了我的问题：

• http://msdn.microsoft.com/en-us/library/bk8ytxz5（v = vs.80）.aspx ： / p>
  
  

  
  

  • ATL是一种快速而简单的方法，可以在C ++中创建一个COM组件， ATL创建一个控件，如果你不需要所有的内置功能，MFC自动提供。

    
    
    

    不真的回答我的问题，因为：

    
    
    
    
    

    • 我不能使用COM。

    
    

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

    
    
  
  

  • MFC允许您创建完整的应用程序，ActiveX控件，如果你已经使用MFC创建了一个控件，你可能希望在MFC中继续开发。在创建一个新控件时，如果你不需要所有的MFC的内置功能，可以考虑使用ATL。

    
    
    

    也不回答我的问题，因为：

    
    
    
    
    

    • 我真的不知道ActiveX 是什么。

    
    

    • 看起来好像微软不鼓励使用

      MFC的内置选项卡，但是我不知道为什么。

    
    
  
  

  • 一般来说，这并不能回答我的问题

  
  

$ ，因为它不能解释缺点 b
$ b

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

• 如何决定是否对新的C ++项目使用ATL，MFC，Win32或CLR？

  
  
  
  
  

  • ATL& MFC在某些方面比较棘手。 [[No kidding！]] 我会引荐你
    
    

    明显

    / em>，这不回答我的问题。）

  
  



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




（最近几天内，同时尝试学习两者）：





• ATL基于on模板或编译时多态性。
  
  
  
  
  • ATL方法通常是非虚拟的，并且倾向于返回引用。
  
  


• MFC基于虚拟方法或运行时多态性。
  
  
  
  
  • MFC方法
  ：
  
  
  
  
  • 两者都使用消息映射（ BEGIN_MSG_MAP 与 BEGIN_MESSAGE_MAP ... big deal）
  
  
  • 将Win32方法封装到类中
  
  
  • 似乎都有类似的类 CWnd 与 CWindow
  
  
  
  
  

  但是，如果没有真正的区别，除了编译时vs.运行时方面，那么为什么它们都存在？

  解决方案

  div>

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

  
  
  

  ，如果你不做任何花哨，使用ATL。这是伟大的简单的用户界面与COM投入。

  
  
  

  长的答案：
  MFC是在90年代初建成的试用这种新的语言称为C ++和将其应用于Windows。

  
  
  

  
  
  

  时间库是非常原始的，这是因为C ++语言和编译器是新的，微软随着Office的发展而建立起来。

  
  
  

  由于这个历史，MFC ：

  
  
  1. 有一个相当笨重的设计。它开始作为围绕Windows API的轻包装，但增长。有一些小的特性，必须发明，因为编译器和语言只是不支持他们。没有模板，他们发明了一个字符串类，他们发明了列表类，他们设计了自己的运行时类型识别等。
  
  
  2. 封装20年的Office和Windows演变，整个垃圾加载你可能永远不会使用：单和多文档接口，DDE，COM，COM +，DCOM，文档链接和嵌入（所以你可以嵌入一个word文档在你的应用程序，如果你想），ActiveX控件对象嵌入的Web！），结构化文档存储，序列化和版本控制，自动化（从早期的VBA年），当然MVC。最新版本支持Visual Studio样式窗口对接和Office功能区。基本上雷德蒙德在20年的每一个技术都在某处。这只是巨大的！
  
  
  3. 有一些小问题，错误，解决方法，假设，支持仍然存在，你永远不会使用，它们会导致问题。你需要非常熟悉许多类的实现，以及它们如何在一个体面的项目上进行交互。在调试期间调试MFC源代码是常见的。找到一个15岁的技术说明，一些指针为空导致崩溃仍然发生。假设初始化古文档嵌入的东西可能会以奇怪的方式影响您的应用程序。没有像MFC中的抽象这样的东西，你需要每天使用它的怪癖和内部，它不隐藏任何东西。
  
  
  

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

  
  
  1. 消息映射：因为它们是模板基于类型，检查，如果你拧紧绑定的函数，它不会构建。在MFC中，消息映射是基于宏的，并且是运行时绑定的。这可能导致奇怪的错误，消息路由到错误的窗口，崩溃如果你有不正确的函数或宏定义，或者只是简单地不工作，因为某些东西没有挂接。
  
  COM /自动化：与消息映射类似，COM最初是使用宏运行时绑定，需要大量错误处理并导致奇怪的问题。 ATL以模板为基础，编译时间限制，更容易处理。
  
  
  
  

  这些小的改进使ATL更容易处理一个简单的应用程序，不需要所有的办公室像MFC的功能。有一个简单的用户界面和一些Office自动化投入。它很小，它的快，它的编译时间限制节省你很多时间和头痛。 MFC有一个巨大的类库，可以笨重，很难使用。

  
  
  

  不幸的是ATL停滞不前。它有包装器的Windows API和COM支持，然后它从来没有真的超越了那。当网络启动时，所有这些东西都被忘记为旧的新闻。

  
  
  
  
  
  

  MFC的巨大的足迹使得他们不可能转储，所以它仍然进展缓慢。模板已经合并回到库中，以及其他语言和API增强。 （我没有听说过WTL，直到我看到这个问题。）

  
  
  

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

  
  
  

  只是我的2美分基于使用MFC多年，我现在每天使用它。我在ATL的时候，在几个项目上首次发布了几年。在那些日子里，这是一股新鲜的空气，但从来没有真正去任何地方。然后网络来了，我忘了一切。

  
  
  

  ---

  
  
  

  编辑：这个答案有令人惊讶的长寿。因为它在我的堆栈溢出页面上弹出，我想我会添加一些点缀我原来缺乏的原始答案。

  
  

  Assuming I am only using 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?

  ---

  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't fast? 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 is in the first place.

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

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

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

  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 page for 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.

  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.

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

  • Both use message maps (BEGIN_MSG_MAP vs. BEGIN_MESSAGE_MAP... big deal)
  • Both wrap Win32 methods into classes
  • Both seem to have similar classes CWnd vs. 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?

  解决方案

  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.

  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.

  [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.]

  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.

  Because of this history, 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.

  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:

  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.

  [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.]

  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.

  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.

  [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.]

  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. :)

  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.

  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.

  ---

  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.

  这篇关于MFC和ATL的根本区别是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！