这几天在看侯SIR的《深入浅出MFC》，前面看的我酣畅淋漓，各种内部机制的原理剖析的十分到位，醍醐灌顶。
但是看到最后一部分，也即是大量剖析MFC源代码那部分，小弟看蒙了。感觉很蒙很迷糊。说说我的看法想跟大家讨论一下：如果作为工具，那么MFC确实精美，因为它把不需要你关心的东西都包装了，呈现出来的接口非常的简单。但是正因为这些包装，给想了解它的内部机的人制造成了很大的困难，它的各个类各个函数之间的调用关系极其复杂，经常是呈回路呈网状的，要是跟踪它的执行过程，一会就迷糊掉了，调用层次太多太没有条理。也难怪，人家设计这个东西又不是让你看内部的，是让你开发的，是为了将软件开发流水线化，这样，如果你能熟读MSDN，了解所有用法，它还是一个很强大的application framework的。那么费那么大的劲了解MFC的内在机制到底是不是一件聪明的事呢？因为我觉得MFC内部并不是一个很漂亮的设计，而是一个很晦涩很难懂的设计。对MFC内在机制有所了解当然会很显著地提高用MFC开发的能力，但是它复杂的包装使得想透彻了解它几乎是不可能的（当然是针对我，小弟才疏）。该不该了解？该了解到什么程度？以上是最近学习MFC的疑惑。欢迎各位发表看法！
但是看到最后一部分，也即是大量剖析MFC源代码那部分，小弟看蒙了。感觉很蒙很迷糊。说说我的看法想跟大家讨论一下：如果作为工具，那么MFC确实精美，因为它把不需要你关心的东西都包装了，呈现出来的接口非常的简单。但是正因为这些包装，给想了解它的内部机的人制造成了很大的困难，它的各个类各个函数之间的调用关系极其复杂，经常是呈回路呈网状的，要是跟踪它的执行过程，一会就迷糊掉了，调用层次太多太没有条理。也难怪，人家设计这个东西又不是让你看内部的，是让你开发的，是为了将软件开发流水线化，这样，如果你能熟读MSDN，了解所有用法，它还是一个很强大的application framework的。那么费那么大的劲了解MFC的内在机制到底是不是一件聪明的事呢？因为我觉得MFC内部并不是一个很漂亮的设计，而是一个很晦涩很难懂的设计。对MFC内在机制有所了解当然会很显著地提高用MFC开发的能力，但是它复杂的包装使得想透彻了解它几乎是不可能的（当然是针对我，小弟才疏）。该不该了解？该了解到什么程度？以上是最近学习MFC的疑惑。欢迎各位发表看法！
内部机制是应该了解的，这个我也同意，比如了解view\document\doctemplate之间的关系，相互之间如何协作，比如了解serialization的内部机制和层次关系，比如了解RTTI和动态创建，否则面对一个自己不知道如何运行起来的程序实在是不高明，而且出了错误也不知道是哪部分的问题。
对一些内部机制的了解确实有助于写出更好的程序和调试。好处是大大地！
所以我才在看深入浅出MFC前面部分时觉得那么过瘾。
但是源代码这个东西
不知您怎么看？
MFC内部的调用关系实在是太复杂了（我认为设计的很不好。。），跟踪源代码的话很难看出它的设计主线。
我真觉得那东西（MFC源码）不是给人看的
想听听大家看法
我的出观点是MFC看看理解理解就好，因为自己的出发点就是解决应用（自己的算法，但无奈又要运行在WIN下，且不能跑Console，唯有MFC能一臂之力了），界面需求较少（最多也就是缩到托盘里），
MFC的View很好，能解决了搞UI的的负担，
所以我觉得MFC里Message的路由才是我的重点
至于MFC给出了那些方便的封装，要用的时候查一查就行了,
MFC的设计出发点就是为了减轻负担，那些东西用多了就知道
如果真的要在机理上去较MFC的劲，倒不如把API全给记下来算了,而且做事保准有效率而且够直接，呵呵
小弟愚见，期望拍砖！！！
2、了解MFC到什么程度，主要看你想作什么。若只是MFC使用者，了解类库用法即可；若要成为VC高手，则要深入MFC，了解其机理；若要成为大师级人物的话，不仅要了解其机理，还要看到它的优点及缺点，以及改进的思路。
3、不管MFC会不会OVER，MS会不会倒闭，深入学习MFC是有益的，它会让你触类旁通，以树见林。
你这句话提醒了我：
“自己的算法，但无奈又要运行在WIN下，且不能跑Console，唯有MFC能一臂之力了”
也许程序员和MFC的关系就应如此
据我所知，类库的设计都是复杂的，因为类库要解决的问题本来就是复杂的。
评估一个类库的优秀是否，以下几方面是显而易见的：
1、使用起来很方便。
2、功能是完备的。
3、性能是卓越的。
4、扩展是轻松的。
5、依赖与耦合是极低的。MFC不是在windows上的唯一选择，还有许多选择，比如QT。
有一些库，非常好用，比如STL，BOOST，但若看它们的源代码的话，不是一般的复杂。
QT和MFC的战争
http://blog.csdn.net/szuwangjl/archive/2009/07/14/4347244.aspx
CSDN的登录BUG如何解决啊？真烦啊！
重来一帖
http://blog.csdn.net/szuwangjl/archive/2009/07/14/4347244.aspx
#define ___ main() {
#define ____ printf("HELLO WORLD");
#define _____ }
#define ______ ___ ____ _____//a.cpp
______
ps:跟ATL比起来，MFC只是个小屋而已
让你们见笑了,呵呵
View/Document还是要看看的...
老外那本WINDOWS程序设计还没
不过看过咱中国那本山寨的WINDOWS程序设计的一部分
对SDK有少许了解
哥们能不能给介绍下看WINDOWS程序设计（老外版）的必要性
也好让我有个清楚的认识
呵呵
因为下次开发可能不需要mfc了。
但是长期使用mfc的话，还是需要了解的，那样写出来的程序质量会高一点。
为什么总是会静不下心来看呢。
最流行，最稳定，功能完善，对多线程支持最彻底的一个框架，采用单继承，构成关系清楚明了！代码清晰直接易懂，例如有些库明明是HWND的数据类型她硬是要变成uint32，明明是RECT结构她硬是要变成她自己的Rect结构，这样就更绕弯子了。[OWL5.0]
已经死亡的项目，继承者是OWLNext，采用多继承比MFC更复杂，对多线程支持不及MFC完善，直到5.0版本依然可以看到大量使用const char*、char*这样的代码，你应该明白这代表着什么。历史做出了正确的选择。[wxWidge]
卖力地模仿MFC，目前已经很完善，但对多线程支持几乎空白（多GUI线程）。例如在创建窗口时不使用线程同步，在窗口过程WndProc中也不使用线程同步。支持跨平台，但不要拿跨平台来说事，使用同一份源代码跨平台的软件都是缺乏竞争力的，因为它不能发挥平台本身的优势，没法跟原生程序相比。所以大凡跨平台的软件都是一些专有软件或者是大公司的软件（你不用也得用）。[VCF]
一个较新的框架，与stl融合，支持Action等概念，但不成熟，对多线程支持也很弱。[WTL]
基于ATL和模板技术的小型库（我不敢说它是一个框架），开发ActiveX控件的首选，但它还很原始不适合用来开发较大的软件。看一个GUI框架是否优秀不要主要看它的消息映射，FRAME/DOC/VIEW很难接受呀什么的，这是次要的。
抛开这个框架的流行程度不说（越多人用当然就越好了），看一个框架主要看它的模型，也就是说它的核心对多线程的支持程度，然后才是它的层次构成和消息映射等方面。核心对多线程的支持是这个框架的骨架，其他的什么App/Wnd对象等都是在这个骨架上铺层皮而已。为什么MFC很多类都有FromHandle()这个函数？以CWnd为例，因为多个线程同时操作一个C++的CWnd对象时会涉及同步问题，所以MFC采取的策略是将一个Windows系统的HWND对象映射成无数个C++的CWnd对象，每个线程操作属于自己的私有CWnd对象，这样就不会破坏CWnd对象的数据和状态，MFC就承担起对CWnd的线程同步责任，而Windows系统则会承担起对HWND所代表的窗口的线程同步责任。所以为什么在主线程内创建的窗口要在附属线程中使用时需要用CWnd::FromHandle(HWND)这样的方法，这种生态现象是由MFC内部形态决定的。
建议有水平的朋友多看看afxstate.cpp和afxtls.cpp这两个文件。
一直不明白MFC封装sdk api时为什么使用钩子而不用其他的方法？