Boost 程式庫**不應**使用 Boost 或 C++ 標準程式庫以外的程式庫。

Boost 程式庫**應**使用其他 Boost 程式庫或 C++ 標準程式庫，但僅限於效益大於成本的情況。

使用其他程式庫元件的效益可能包括程式碼更清晰、更易理解，降低開發和維護成本，以及重複使用知名且可信賴的建構模組所帶來的保障。

成本可能包括元件之間不必要的耦合，以及額外的編譯和執行時期成本。如果額外元件的介面很複雜，使用它可能會降低程式碼的可讀性，從而實際上增加開發和維護成本。

當一個程式庫使用第二個程式庫，而第二個程式庫又使用第三個程式庫，依此類推時，耦合的負面影響就會變得明顯。最糟糕的耦合形式需要使用者理解每個耦合的程式庫。耦合也可能降低程式庫的可移植性——即使在所有使用的程式庫都是自給自足的情況下也是如此（請參見下面 <iostream> 程式庫的 questionable usage 範例）。

**肯定應該使用其他 Boost 元件的範例：** boost::noncopyable（位於 boost/utility.hpp 中）具有相當大的效益；它簡化了程式碼，提高了可讀性，並表明了意圖。由於耦合有限，成本很低；noncopyable 本身不使用其他類別，其標頭檔僅包含輕量級標頭檔 <boost/config.hpp> 和 <cstddef>。完全沒有執行時期成本。由於成本如此之低，而效益如此之高，其他 Boost 程式庫在需要時應該使用 boost::noncopyable，除非在特殊情況下。

**可能可以使用標準程式庫元件的範例：**提供診斷輸出作為除錯輔助可以是程式庫的一個不錯的功能。然而，使用標準程式庫 <iostream> 可能會涉及很多額外成本，尤其是在應用程式中其他地方不太可能使用 <iostream> 的情況下。在某些 GUI 或嵌入式應用程式中，與 <iostream> 耦合將是一個缺點。請考慮重新設計相關的 Boost 程式庫，以便使用者提供診斷輸出機制。

**不應使用其他 Boost 元件的範例：** boost dir_it 程式庫具有相當大的耦合和執行時期成本，更不用說不支援作業系統的可移植性問題。雖然在需要目錄迭代時完全合適，但另一個 Boost 程式庫使用 dir_it 僅僅為了在開啟檔案之前檢查檔案是否可用是不合理的。C++ 標準程式庫檔案開啟功能可以以更低的成本完成這項工作。不要為了使用 Boost 程式庫而使用 dir_it。