當前位置:才華都>教師之家>試題>

Windows面試題

試題 閱讀(2.64W)

問MainFrm,CDocument和CView類之間的關係,

Windows面試題

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開發面試中最經常問到得問題,也是很有深度的一個問題。

有兩個帖子對該問題討論的比較深刻:

說法一:

虛擬函式實現佔用記憶體較大

侯捷在《深入淺出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:這裡有一篇對比訊息對映機制和虛擬函式機制效率的簡單模擬實驗

結論,該說法不靠譜!

說法三:

為了未來的可擴充套件性。相容新的系統級的訊息。

我不是很清楚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面向無連線,通訊前不需要建立連線;

2)TCP保障可靠傳輸(按序、無差錯、不丟失、不重複);UDP不保障可靠傳輸,使用最大努力交付;

3)TCP面向位元組流的傳輸,UDP面向資料報的傳輸。

TCP為什麼不是兩次連線?而是三次握手?

如果A與B兩個程序通訊,如果僅是兩次連線。可能出現的一種情況就是:A傳送完請報文以後,由於網路情況不好,出現了網路擁塞,即B延時很長時間後收到報文,即此時A將此報文認定為失效的報文。B收到報文後,會向A發起連線。此時兩次握手完畢,B會認為已經建立了連線可以通訊,B會一直等到A傳送的連線請求,而A對失效的報文回覆自然不會處理。依次會陷入B忙等的僵局,造成資源的浪費。

connect方法會阻塞,請問有什麼方法可以避免其長時間阻塞?

可以考慮採用非同步傳輸機制,同步傳輸與非同步傳輸的主要區別在於同步傳輸中,如果呼叫recvfrom後會一致阻塞執行,從而導致呼叫執行緒暫停執行;非同步傳輸機制則不然,會立即返回。

網路程式設計中設計併發伺服器,使用多程序與多執行緒,請問有什麼區別?

答案一:

1,程序:子程序是父程序的複製品。子程序獲得父程序資料空間、堆和棧的複製品。

2,執行緒:相對與程序而言,執行緒是一個更加接近與執行體的概念,它可以與同進程的其他執行緒共享資料,但擁有自己的棧空間,擁有獨立的執行序列。兩者都可以提高程式的併發度,提高程式執行效率和響應時間。

執行緒和程序在使用上各有優缺點:執行緒執行開銷小,但不利於資源管理和保護;而程序正相反。同時,執行緒適合於在SMP機器上執行,而程序則可以跨機器遷移。

答案二:

根本區別就一點:用多程序每個程序有自己的地址空間(address space),執行緒則共享地址空間。所有其它區別都是由此而來的:

1。速度:執行緒產生的速度快,執行緒間的通訊快、切換快等,因為他們在同一個地址空間內。

2。資源利用率:執行緒的資源利用率比較好也是因為他們在同一個地址空間內。

3。同步問題:執行緒使用公共變數/記憶體時需要使用同步機制還是因為他們在同一個地址空間內。等等

Windows程式設計的知識點,如訊息機制,一個自定義訊息如何實現。

自定義訊息共分為3步驟:

1) 自定義訊息:#defineWM_MYMSGWM_USER+1

2) 在標頭檔案中宣告函式:afx_msg voidonMyMsg();

3) 在訊息對映中新增對應關係:

//BEGIN_MESSAGE_MAP(CDefMsgDemoDlg,CDialog)//END_MESSAGE_MAP()

ON_MESSAGE(WM_MYMSG,onMyMsg)

4)定義函式void onMyMsg();

核心即:函式原型、關聯訊息與訊息響應函式的巨集、函式實現。

SNMP協議

簡單網路管理協議——應用層協議.

包括5種資料包:Get-Request;Get-Next-Request;Set-Request, Get-Response; Trap;

RAW套接字

廣泛應用於高階網路程式設計,如SNIFFER、拒絕服務、IP欺騙都是通過原始套接字實現的。

視窗建立的步驟:

1)設計視窗類(填充結構體)à2)註冊視窗類RegisterClassà3)建立視窗;4)顯示ShowWindow&更新視窗UpdateWindowà4)迴圈獲取訊息GetMessage(){翻譯(轉換)TranslateMessage訊息、處理訊息DispathMessage(將訊息交付給視窗過程進行處理)}。

當觸發按鈕以後發生了什麼?

1)比如點選滑鼠左鍵後,作業系統首先會感知到該事件;2)作業系統將事件其轉化為訊息;3)作業系統將訊息投遞到對應程式(執行緒)的訊息佇列中;4)應用程式(執行緒)從訊息佇列中通過GetMessage獲取訊息,並通過DispathMessge將訊息交付給作業系統;5)作業系統通過設計視窗類時指定的視窗過程對對訊息進行處理。

你平時是如何除錯程式的?(引申)當一個程式在自己機器上執行正常,但是在其他機器上程式執行崩潰,如何查詢原因?

斷點除錯:

值:檢視變數(Variables)、表示式、記憶體(Memory)、暫存器(Register)的值。

程序控制:VC允許被中斷的程式繼續執行、單步執行和執行到指定游標處,分別對應快捷鍵F5、F10/F11和CTRL+F10。

其他除錯手段:系統提供一系列特殊的函式或者巨集來處理Debug版本相關的資訊TRACE、ASSERT、VERIFy。Ctrl+B開啟斷點設定。

執行崩潰,如何查詢原因? [提示後],可以通過列印語句來發現錯誤!

執行緒、視窗、訊息佇列三者之間的關係?

MSDN上如是說:

Thethread to which the message is posted musthave created a message queue,or elsethe call to PostThreadMessagefails.

並提供瞭如下兩種解決方法:

it fails, call theSleep function and call PostThreadMessageagain. Repeat untilPostThreadMessage succeeds.

【面試官】說:一個執行緒對應一個或多個視窗(建立的關係),同時一個執行緒對應了一個訊息佇列。

【總結如下】:

1.在MFC程式框架裡面,CWinThread專門負責執行緒建立的,它可以建立使用者介面執行緒,及工作者執行緒。其中使用者介面執行緒是包含訊息佇列的,而工作者執行緒是不包含訊息佇列的。即【一句話】:使用者介面執行緒對應一個訊息佇列。

Thread類和CWnd類都派生自CCmdTarget,而CDialog對話方塊類、檢視類CView都派生自CWnd。

【深入淺出MFC裡一句話】:不是每一個視窗都產生一個執行緒(因為要付出昂貴的執行緒切換代價)。即,深入理解之:一個執行緒可以對應多個視窗。主執行緒可以創建出其所要的全部視窗。

【結論】一個UI執行緒就1組訊息佇列集合,一個執行緒可以建立多個視窗。

OSI7層模型是什麼?每層有哪些協議?

應用層FTP、Telnet、SMTP、HTTP、RIP、NFS、DNS表示層示例:加密,ASCII等會話層示例:RPC,SQL等傳輸層示例:TCP,UDP,SPX

網路層示例:IP協議、ICMP協議、ARP協議、RARP協議資料鏈路層示例:ATM,FDDI等物理層示例:Rj45,802.3等

請寫出下列服務使用的預設埠POP3、SMTP、FTP、MSN、DNS、SQL

埠:21服務:FTP

埠:22服務:SSH埠:23服務:Telnet埠:25服務:SMTP埠:80服務:HTTP

埠:110服務:PostOfficeProtocol-Version3(pop3)埠:569服務:MembershipMSN埠1433和1434服務:SQL

DNS協議執行在UDP之上,使用埠號53