MFC、WTL 、ATL、STL联系与区别
STL的代码从广义上讲分为三类：algorithm（算法）、container（容器）和iterator（迭 代器），几乎所有的代码都采用了模板类和模版函数的方式，这相比于传统的由函数和类 组成的库来说提供了更好的代码重用机会。
ATL是一个产生C++/COM代码的框架，就如同C语言是一个产生汇编代码的框架ATL又不同于MFC，它完全面向COM组件，其技术路线也不同于MFC，MFC使用的是C++中的继承、封装、嵌套等常规技术，而ATL使用了C++中模板、多继承等高级技术，甚至还用到了STL。
WTL全称为Windows Template Library，构架于ATL之上，采用C++模板技术来包装大部窗口控制，并给出一个与MFC相似的应用框架。
在visual C++ 6.0中，ATL和MFC代表了两种不同的框架，分别面向不同类型的基于Windows的开发。ATL提供了一种框架来实现创建COM客户机和服务器所必须的样板文件代码；MFC代表了创建独立的Windows应用的一种简单、一致的方法。这两种框架都可以用来创建ActiveX控件。
ATL是ActiveX Template Library的缩写，它是一套C++模板库。使用ATL能够快速地开发出高效、简洁的代码，同时对COM组件的开发提供最大限度的代码自动生成以及可视化支持。为了方便使用，从MicrosoftVisualC++5.0版本开始，Microsoft把ATL集成到VisualC++开发环境中。1998年9月推出的VisualStudio6.0集成了ATL3.0版本。
在ATL产生以前，开发COM组件的方法主要有两种：一是使用COMSDK直接开发COM组件，另一种方式是通过MFC提供的COM支持来实现。
ATL的基本的COM支持
ATL的目标是使开发者不必重写IUnknown, IDispatch, IclassFactory和其它的分支以将常规的DLL和EXE变成基于COM的DLL和EXE。从这个角度讲，ATL是一个比MFC精简的多的框架，它设计和生成时就考虑了COM支持。它使用基于模板的方法，通过继承ATL提供的模板，开发者可以加入各种COM功能片断。
由于ATL是为了便于编写组件对象而存在的，所以只提供了简单的界面类，相当于MFC的窗口类（CWnd）和对话框类（CDialog）。幸运的是这些类非常的灵活，能够在其基础上构建象WTL这样的附加类。
直接使用COMSDK开发COM组件是最基本也是最灵活的方式。通过使用Microsoft提供的开发包，我们可以直接编写COM程序。但是，这种开发方式的难度和工作量都很大，一方面，要求开发者对于COM的技术原理具有比较深入的了解（虽然对技术本身的深刻理解对使用任何一种工具都是非常有益的，但对于COM这样一整套复杂的技术而言，在短时间内完全掌握是很难的）；另一方面，直接使用COMSDK要求开发人员自己去实现COM应用的每一个细节，完成大量的重复性工作。这样做的结果是，不仅降低了工作效率，同时也使开发人员不得不把许多精力投入到与应用需求本身无关的技术细节中。虽然这种开发方式对于某些特殊的应用很有必要，但这种编程方式并不符合组件化程序设计方法所倡导的可重用性，因此，直接采用COMSDK不是一种理想的开发方式。
使用MFC提供的COM支持开发COM应用可以说在使用COMSDK基础上提高了自动化程度，缩短了开发时间。MFC采用面向对象的方式将COM的基本功能封装在若干MFC的C++类中，开发者通过继承这些类得到COM支持功能。为了使派生类方便地获得COM对象的各种特性，MFC中有许多预定义宏，这些宏的功能主要是实现COM接口的定义和对象的注册等通常在COM对象中要用到的功能。开发者可以使用这些宏来定制COM对象的特性。
随着Internet技术的发展，Microsoft将ActiveX技术作为其网络战略的一个重要组成部分大力推广，然而使用MFC开发的ActiveXControl，代码冗余量大，即所谓的“肥代码”（FatCode），而且必须要依赖于MFC的运行时刻库才能正确地运行。虽然MFC的运行时刻库只有部分功能与COM有关，但是由于MFC的继承实现的本质，ActiveXControl必须背负运行时刻库这个沉重的包袱。如果采用静态连接MFC运行时刻库的方式，这将使ActiveXControl代码过于庞大，在网络上传输时将占据宝贵的网络带宽资源；如果采用动态连接MFC运行时刻库的方式，这将要求浏览器一方必须具备MFC的运行时刻库支持。总之，MFC对COM技术的支持在网络应用的环境下也显得很不灵活。
MFC对COM和OLE的支持确实比手工编写COM程序有了很大的进步。但是MFC对COM的支持还不够完善和彻底，例如对COM接口定义的IDL语言，MFC并没有任何支持，此外对于近些年来COM和ActiveX技术的新发展MFC也没有提供灵活的支持。这是由MFC设计的基本出发点决定的。MFC被设计成对Windows平台编程开发的面向对象的封装，自然要涉及Windows编程的方方面面，COM作为Windows平台编程开发的一个部分也得到MFC的支持，但是MFC对COM的支持是以其全局目标为出发点的，因此对COM的支持必然要服从其全局目标。从这个方面而言，MFC对COM的支持不能很好地满足开发者的要求。
对于程序员来说，还有一个区别就是ATL要求你懂得更多的COM知识，这样你才能直接使用ATL来编写COM组件或者控件，而MFC甚至不要求你知道COM是个什么东西就能写出一个ActiveX控件来了。
MFC微软基础类(Microsoft Foundation Classes),实际上是微软提供的,用于在C++环境下编写应用程序的一个框架和引擎,VC++是WinOS下开发人员使用的专业C++ SDK(SDK,Standard SoftWare Develop Kit,专业软件开发平台),MFC就是挂在它之上的一个输助软件开发包。MFC是Win API与C++的结合,API,即微软提供的WinOS下应用程序的编程语言接口,是一种软件编程的规范
如果你编写的控件有GUI（图形用户界面）的话，你最好使用MFC；如果根本不需要GUI，那最好使用ATL编写，当然你也可以选择MFC来编写不可见的控件，但是开销比ATL大，而执行效率却小于ATL；但是有时候这种差别所带来影响可以忽略掉的话，那么我建议你还是用MFC来写，唯一的理由是它开发起来更简单，易于调试。如果你是一个COM的门外汉，却又想使用ATL来编写控件，那么建议你先准备半年时间（保守估计）来学习COM的理论知识
MFC中的数据类型
| BOOL |
|
| BSTR |
32-bit字符指针 |
| BYTE |
8-bit整数，无符号 |
| COLORREF |
32-bit数值，代表颜色值 |
| DWORD |
32-bit整数，无符号 |
| LONG |
32-bit整数，有符号 |
| LPARAM |
32-bit数值，作为窗口函数或callback的参数 |
| LPCSTR |
32-bit指针，指向一个常数字符串 |
| LPSTR |
32-bit指针，指向一个字符串 |
| LPCTSTR |
|
| LPTSTR |
|
| LPVOID |
32-bit指针，指向一个未指定类型的数据 |
| LPRESULT |
32-bit数值，作为窗口函数或callback的返回值 |
| UINT |
Unsigned int |
| WNDPROC |
32-bit指针，指向一个窗口函数 |
| WORD |
16-bit整数，无符号 |
| WPARAM |
窗口函数或callback的一个参数 |
特有的数据类型
| POSITION |
一个数值，代表collection对象中的元素位置，常用于MFC collection classes |
| LPCRECT |
32-bit指针，指向一个不变的RECT结构 |