隨著第九章進入尾聲，又到了小測驗時間！今天也是工作忙碌的 Yoyo，就用幾道簡單的題目放鬆心情吧。

Q1. 下列何者是處理 C++ 編譯器警告的最佳實踐？
A) 如果程式仍然能編譯，就忽略警告。
B) 只有當某些編譯器將警告視為錯誤時，才修復這些警告。
C) 完全依賴編譯器警告來捕捉所有錯誤。
D) 只關注與語法相關的警告。
E) 嘗試在所使用的編譯器支援的最高警告等級下實現零警告編譯。

最佳實踐方式是認真對待編譯器警告，並努力讓程式碼在最高警告等級下無任何告警。這有助於捕捉隱藏的錯誤並提高程式碼品質。

忽視警告可能導致潛在的危險，例如當程式重新移植到其他平臺時，某些語義錯誤可能未被檢測到。隨著開發者經驗的增長，應該習慣於及早修正警告，以減少後續除錯的成本。

Q2. 為什麼過度依賴編譯器警告來捕捉 C++ 程式中的錯誤是危險的？
A) 因為所有編譯器都會生成相同的警告。
B) 因為警告在 C++ 中總是被視為錯誤。
C) 因為編譯器不會允許有警告的程式通過編譯。
D) 因為不同的編譯器對不同的問題給出不同的警告。
E) 因為警告僅針對語法錯誤。

編譯器警告是實現依賴的，不同編譯器對錯誤的診斷存在差異。在將程式碼 pull 到新的編譯環境時，可能看不到原本依賴的警告，導致錯誤難以發現。

編譯器在其設計過程中會根據不同的實作特性產生不同種類的警告。例如，某些編譯器可能偏好檢查記憶體洩漏風險，而另一些則更關注語法矛盾。因此僅依賴單一編譯器的警告不足以全面保障程式碼的穩定性，須兼顧多個開發環境的檢測與測試。

Q3. 以下關於 TR1 智慧指標的敘述，哪一項是正確的？
A) tr1::shared_ptr 參與引用計數，但 tr1::weak_ptr 增加了引用計數。
B) tr1::weak_ptr 當其引用計數為零時自動刪除對象。
C) tr1::shared_ptr 只適用於環狀資料結構。
D) 而 tr1::weak_ptr 不參與引用計數，專門用於打破環狀引用。
E) tr1::weak_ptr 在所有情況下都能直接替代 tr1::shared_ptr。

tr1::shared_ptr 使用引用計數來管理對象生命週期，當最後的共享指標被銷毀時，對象會被自動刪除。而 tr1::weak_ptr 不參與引用計數，用來解決 shared_ptr 在環狀結構中引用計數錯誤的問題。

tr1::weak_ptr 是一種輕量的弱引用指標，可防止資源洩漏。shared_ptr 適用於非環狀架構；若有多個對象之間形成 doubly linked list 時，則可使用 weak_ptr 打破閉環並允許資源回收。

Q4. 若想在 Boost 函式庫新增功能，要經過哪些流程才會被接受？
A) 只要函式庫在 Windows 上可以編譯，就會自動接受。
B) 函式庫通過公開的社群進行討論、改進並審查提交內容。
C) 函式庫是由 Boost 管理員隨機選擇優質程式並撰寫說明。
D) 函式庫必須由 C++ 標準委員會成員撰寫才會被接受。
E) 函式庫需要先出版在書籍中，才會被接受。

Boost 接受新函式庫的過程基於公開的同行評審機制。社群成員對提交的函式庫進行討論、改進和審查，最終通過共識確認是否接受並納入 Boost。

Boost 是一個極為活躍的開源社群，其所有函式庫均需經過嚴格的評審和測試，以確保其功能穩定性和編碼品質。Boost 的很多函式庫後來被納入 C++ 標準，足見其對 C++ 社群的重要影響力。TR1 中的多數功能都是從 Boost 衍生而來的。