摘要: 要點：絕對不應該在構造函數和析構函數中調用虛函數。  閱讀全文      摘要: 有兩個相同的棧，一個里面放著自大到小排列的數，棧頂的數最小，另一個棧是空的.
不允許利用其它的數據結構，只能利用這兩個棧，要求把第一個棧里的數字反過來，從
小到大排列，結果還放在原來的那個棧里面。  閱讀全文      摘要: 單元測試（模塊測試）是開發者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數的行為。例如，你可能把一個很大的值放入一個有序list 中去，然后確認該值出現在list 的尾部?；蛘?，你可能會從字符串中刪除匹配某種模式的字符，然后確認字符串確實不再包含這些字符了。

單元測試是由程序員自己來完成，最終受益的也是程序員自己。可以這么說，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試。執行單元測試，就是為了證明這段代碼的行為和我們期望的一致。

要進行充分的單元測試，應專門編寫測試代碼，并與產品代碼隔離。個人認為，比較簡單的辦法是為產品工程建立對應的測試工程，為每個類建立對應的測試類，為每個函數（很簡單的除外）建立測試函數。  閱讀全文      摘要: 測試用例就是測試數據及與之相關的功能的一個特定集合，它是為驗證被測試程序（為測試程序路徑或驗證是否符合特定功能等方面的需求）而設計的。在單元測試過程中，測試用例的設計應與復審工作相結合，根據設計的測試用例選取不同的測試數據，將增加發現各類錯誤的可能性；另外，根據項目的具體情況確定測試用例項。如：測試用例編號、用例輸入、用例預期輸出、被測單元的版本號、實際輸出等。單元測試用例的設計既可以使用白盒測試也可以使用黑盒測試，但以白盒測試為主，黑盒測試側重于功能，白盒測試側重于邏輯。

白盒測試進入的前提條件是測試人員已經對被測試對象有了一定的了解，基本上明確了被測試軟件的邏輯結構。具體過程就是針對程序邏輯結構設計和加載測試用例，驅動程序執行，檢查在不同點程序的狀態，以確定實際的狀態是否與預期的狀態一致。

一般來說，為了度量測試的完整性，測試工作中通常要求達到一定的覆蓋率要求。因為通過覆蓋率的統計可以知道測試是否充分，對軟件的哪個部分所做的測試不夠，指導我們如何設計增加覆蓋率的測試用例。這樣就能夠提高測試質量，盡量避免設計無效的用例。

在白盒測  閱讀全文      摘要: 最常見的通配符是?和*。其中，?可以代表一個字符（不能沒有），*可以代表任意多個字符（可以為空）。
首先是?，根據?的功能，?表示任意字符，也就是說在匹配過程中，?永遠匹配成功。本質上，?并沒有修改算法，而僅僅修改了匹配規則——遇到?則一定匹配。
然而*與此不同，*的作用是匹配任意多個字符，顯然我們不能簡單的修改匹配過程而滿足要求。如果我們重新思考*的作用，我們會發現*的另一個作用就是分割P串，即如果P=P1*P2，那么與其說*代表匹配任意多個字符，不如說P的匹配條件是在匹配P1子串后再匹配P2子串。
因此，可以寫出帶通配符的字符串匹配算法  閱讀全文