兩年前從網上看到一道面試題：用兩個棧（stack）實現乙個佇列（queue）。覺得不錯，就經常拿來面試，幾年下來，做此題的應該有幾十人了。通過對面試者的表現和反應，有一些統計和感受，在此做個小結。
用c++描述，題目大致是這樣的：
已知下面stack類及其3個方法push、pop和count，請用2個stack實現queue類的入隊(enqueue)出隊(dequeue)方法。
class stack
;
class queue
;
這道題應該不算難，比起《程式設計之美》中微軟那些什麼「翻烙餅」的面試題，難度上差遠了。況且，由於時間關係，我一般也不要求面試者寫**，只描述清楚思路即可。出這道題，主要考察3點：
1.在短時間內，能不能找到解決這道題的足夠清晰的思路（思維是否敏捷、清晰）。
2.能不能在單向表述中，清楚地描述自己的思路和想法（表述能力是否達到要求）。
3.對於某些具體細節，能不能考慮到（是否足夠細緻）。
總體上，以10人為例，實際的結果大致是：
1.8個人可以找到解決答案，2個人無法找到答案（即使進行了必要的提示，曾經有位號稱美國mit深造2年，之後在google美國公司工作過8個月的兄弟，也沒做出來）。
2.8個找到答案的人中，6個找到的方法相同，2個人找到其它變種。
3.在這8個人中，有1個人可以不經提示，同時想到大眾方法和變種。
大多數人的思路是：始終維護s1作為儲存空間，以s2作為臨時緩衝區。
入隊時，將元素壓入s1。
出隊時，將s1的元素逐個「倒入」（彈出並壓入）s2，將s2的頂元素彈出作為出隊元素，之後再將s2剩下的元素逐個「倒回」s1。
見下面示意圖：
上述思路，可行性毋庸置疑。但有乙個細節是可以優化一下的。即：在出隊時，將s1的元素逐個「倒入」s2時，原在s1棧底的元素，不用「倒入」s2（即只「倒」s1.count()-1個），可直接彈出作為出隊元素返回。這樣可以減少一次壓棧的操作。約有一半人，經提示後能意識到此問題。
上述思路，有些變種，如：
入隊時，先判斷s1是否為空，如不為空，說明所有元素都在s1，此時將入隊元素直接壓入s1；如為空，要將s2的元素逐個「倒回」s1，再壓入入隊元素。
出隊時，先判斷s2是否為空，如不為空，直接彈出s2的頂元素並出隊；如為空，將s1的元素逐個「倒入」s2，把最後乙個元素彈出並出隊。
有些人能同時想到大眾方法和變種，應該說頭腦還是比較靈光的。
相對於第一種方法，變種的s2好像比較「懶」，每次出隊後，並不將元素「倒回」s1，如果趕上下次還是出隊操作，效率會高一些，但下次如果是入隊操作，效率不如第一種方法。我有時會讓面試者分析比較不同方法的效能。我感覺（沒做深入研究），入隊、出隊操作隨機分布時，上述兩種方法總體上時間複雜度和空間複雜度應該相差無幾（無非多個少個判斷）。
真正效能較高的，其實是另乙個變種。即：
入隊時，將元素壓入s1。
出隊時，判斷s2是否為空，如不為空，則直接彈出頂元素；如為空，則將s1的元素逐個「倒入」s2，把最後乙個元素彈出並出隊。
這個思路，避免了反覆「倒」棧，僅在需要時才「倒」一次。但在實際面試中很少有人說出，可能是時間較少的緣故吧。
以上幾個思路乍看沒什麼問題了，但其實還是有個細節要考慮的。其實無論什麼方法和情況，都要考慮沒有元素可供出隊時的處理（2個棧都為空的時候，出隊操作一定會引起異常）。在實際寫**時，忽略這些判斷或異常處理，程式會出現問題。所以，能不能考慮到這些細節，也體現了個人的素養。
個人感覺，這道題確實有助於我鑑別應聘的人。但對於面試，畢竟還是要看面試者的綜合素質，一道（或幾道）題定生死不可取。
用兩個棧實現乙個佇列 用兩個佇列實現乙個棧
做題之前，我們先來回顧一下 棧和佇列的相同點以及不同點 便於做題時的應用！1.區別與聯絡 相同點 1 棧和佇列都是控制訪問點的線性表 2 棧和佇列都是允許在端點處進行資料的插入和刪除的資料結構 不同點 1 棧遵循 後進先出 lifo 的原則，即只能在該線性表的一頭進行資料的插入和刪除，該位置稱為 棧...
用兩個棧實現乙個佇列，用兩個佇列實現乙個棧
t deletehead 頭部刪除節點 while s1.empty t ret s2.top s2.pop return ret private stacks1 stacks2 問題2 用兩個佇列實現乙個棧 問題分析 用兩個佇列實現乙個棧，刪除時，由於佇列是先進先出的，而棧是後進先出，因此假設現在...
用兩個棧實現乙個佇列 用兩個佇列實現乙個棧
思路 棧 先進後出，佇列 先進先出 如果轉化 1.將內容先push進乙個棧instack，2.判斷outstack是否為空，空 將棧instack中的元素pop 刪除並返回陣列的最後乙個元素 並push進outstack，非空 直接出棧 3.出棧時，先push進instack先從outstack出來...