问MainFrm,CDocument和CView类之间的关系,

　　MainFrm为框架类，包含应用程序外框所包含部分。CView为视图类，用于显示数据的空白区域窗口。

　　CDocument为文档类。

　　MFC提供了文档/视类结构，采用数据本身和显示分离的机制。其中文档类CDocument用于数据的存储和加载，视类CView用于数据的显示与修改。

　　Dialog和ModuelDialog不同用法

　　1）类型不同

　　MoudleDialog 模态对话框，属于垄断对话框，例如打开对话框，点击打开后不能再执行其他操作，会发出“嘟嘟嘟”的声音；

　　非模态对话框，属于非垄断对话框，利用查找对话框，点击查找同时可以执行其他操作；

　　即：非模态不垄断；模态垄断。

　　2）用法不同

　　CDialog::Create ：to create amodelessdialog box

　　CDialog::DoModal ：Call thismember function to invoke the modal dialog box andreturn the dialog-box resultwhen done

　　windows消息系统由哪几部分构成?

　　答：由一下3部分组成：

　　1.消息队列：操作系统负责为进程维护一个消息队列，程序运行时不断从该消息队列中获取消息、处理消息；

　　2.消息循环：应用程序通过消息循环不断获取消息、处理消息。

　　3.消息处理：消息循环负责将消息派发到相关的窗口上使用关联的窗口过程函数进行处理。

　　什么时候必须重写拷贝构造函数?

　　答：当构造函数涉及到动态存储分配空间时，要自己写拷贝构造函数，并且要深拷贝。

　　什么是消息映射?

　　答：消息映射就是让程序员指定MFC类（有消息处理能力的类）处理某个消息。然后由程序员完成对该处理函数的编写，以实现消息处理功能。

　　如何定义和实现一个类的成员函数为回调函数?

　　答：

　　所谓的回调函数，就是预先在系统的对函数进行注册，让系统知道这个函数的存在，以后，当某个事件发生时，再调用这个函数对事件进行响应。

　　定义一个类的成员函数时在该函数前加CALLBACK即将其定义为回调函数，函数的实现和普通成员函数没有区别

　　MFC为何使用消息映射表而不用虚函数？

　　这个问题是windows开发面试中最经常问到得问题，也是很有深度的一个问题。

　　有两个帖子对该问题讨论的比较深刻：

　　http://topic.csdn.net/u/20090822/16/4cf5d189-0e5e-41ff-9ba3-c7eaf2f6da74.html

　　http://topic.csdn.net/u/20090316/22/8b067591-6a17-4970-b224-41ab589294b3.html

　　说法一：

　　虚函数实现占用内存较大

　　侯捷在《深入浅出MFC》中说微软使用消息映射机制而不用虚函数，是因为虚函数空间代价的原因。在当前MFC2.0版本发布的时候是92年，pc的内存才几M。一个类的虚表的大小就是虚函数的个数*一个指针的大小。

　　假设windows的通用消息有200个，那么CWnd类的虚表就有 200*4个byte = 800byte，CWnd类的所有派生类均copy了一份CWnd的虚表vtable，然后自己的虚函数往后加CWnd类的虚表的后头。

　　（至于有人说CWnd类的派生类能共享CWnd的虚表，这个说法不靠谱。因为派生类自己的虚函数值加在基类的虚函数表项的最后的。如果CWnd派生了CWndChildA 和 CWndChildB，且两个孩子均有自己的虚函数，那么都往CWnd类的后面加，岂不是冲突了？）。

　　也就是系统内所有的CWnd类的派生类都要承受 800byte的代价。假设有100个类派生自CWnd 那么代价就是800*100byte 也就是 80K。这在当时内存很紧张的情况下，已经是一种巨大的内存消耗了！这里需要注意一点：vtable是和类绑定在一起的，而不是和类对象（也叫类的实例）绑定在一起的，类的实例仅增加一个指向该向类的vtable的指针而已。也就是说，如果你有100个CWnd派生类，哪怕你生成了100000个派生类的实例，vtable占用的内存也是80K。

　　看来在当时的环境看来，MFC没有采用虚函数，内存的确是一个考虑。

　　但是放在现在看，这点内存消耗确实微不足道的！也就是说，如果现在重新设计MFC的消息机制，如果不采用虚函数，并非因为虚函数的空间浪费问题。结论：这个说法靠谱。

　　说法二：

　　消息映射机制效率比虚函数效率高。

　　因为那么多消息ID，如果找到其对应的消息处理函数，switch是不可少的！（可以hash？哦哦，的确可能，不过mfc里面可没这么做？mfc里面怎么做的我也不清楚）

　　MFC中采用的是消息映射的机制，而没有用虚函数的机制，因为消息有很多，如果用虚函数机制，需要给每个消息定义一个虚函数，在分派消息时，程序需要逐一判断是哪一个消息，找到合适的分支后再调用相应的虚函数；而通常情况下，应用程序不需要响应太多的消息，消息映射方式只需要判断程序想要响应的这些消息即可，所以开销小。

　　也就是说，MFC采用了消息映射而没有采用虚函数，是从对消息的响应机制来考虑的。消息映射，就可以仅实现自己感兴趣的消息，这样switch时就可以快一点。

　　不过话又说回来，对一个非自己感兴趣的系统消息来了以后，就需要遍历消息网，层层的向基类查找直到找到对应的消息处理函数！这本身也很浪费时间！也许这种情况比较少见吧，否则的话，消息映射的消息响应时间并不比虚函数来的快！因为虚函数最多只需一次遍历，而且，如果可以采用hash技术，更快！

　　如果说，大多数消息都是系统的消息，那么消息映射的迭代查找消息函数的方式并不比虚函数的switch来的快！

　　PS：这里有一篇对比消息映射机制和虚函数机制效率的简单模拟实验

　　http://blog.csdn.net/hjsunj/archive/2008/01/10/2034314.aspx结论，该说法不靠谱！

　　说法三：

　　为了未来的可扩展性。兼容新的系统级的消息。

　　我不是很清楚MS设计消息映射的初衷，但是感觉它着眼点更侧重于增加新消息很容易，而不是节省内存。

　　如果我们使用虚函数机制实现，恐怕对于每个可能的消息我们都必须在基类中定义一个虚函数，而其首要的困难就是你无法猜测未来会出现什么消息，也无法确定需要定义什么样函数原型的虚函数。而使用消息映射，解决这个问题则相对容易，因为这将由未来的程序设计者决定他们的'消息该如何处理。

　　对于系统的新增消息，消息映射支持起来较方便。虚函数想要支持就需要改动基类添加虚函数。

　　对于自定义的消息，无论消息映射和虚函数都可以很好的支持。

　　那么虚函数方式如何支持自定义消息?

　　自定义消息是不需要加到基类的。基类可以加个虚函数，OnMessage(xxx), 然后有自定义消息的类实现之，用switch转换成相应虚函数调用，不是自己的消息再传给基类。

　　结论：这个说法靠谱。

　　sendMessage与postMessage区别？

　　不同点：sendMessage发送完毕以后需要等待处理完才返回；而postMessage发送消息后立即返回。

　　Do not post the WM_QUIT message usingPostMessage; use thePostQuitMessage function.

　　postMessage将消息放置到消息队列中，不等待线程处理消息就立即返回。

　　sendMessage发送指定的消息到窗口，并会调用窗口过程，直到窗口过程处理完毕后才返回。

　　TCP的重发机制是怎么实现的？

　　1.滑动窗口机制，确立收发的边界，能让发送方知道已经发送了多少（已确认）、尚未确认的字节数、尚待发送的字节数；让接收方知道（已经确认收到的字节数）。

　　2.选择重传，用于对传输出错的序列进行重传。

　　TCP和UDP的区别？

　　1）TCP面向连接（三次握手机制），通信前需要先建立连接；UDP面向无连接，通信前不需要建立连接；