問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面向無連接,通信前不需要建立連接;
本文來源:http://www.nvnqwx.com/shiti/2617696.htm