Boost 库重用：成本与收益权衡
Boost 库**不应该**使用除了 Boost 或 C++ 标准库之外的其他库。
Boost 库**应该**使用其他 Boost 库或 C++ 标准库，但仅在收益超过成本时。
使用其他库组件的好处可能包括更清晰、更易理解的代码，降低开发和维护成本，以及重用知名且可靠的构建块带来的保证。
成本可能包括组件之间不希望的耦合，以及增加的编译和运行时成本。如果附加组件的接口很复杂，使用它可能会使代码可读性降低，从而实际上增加了开发和维护成本。
当一个库使用第二个库，而第二个库又使用第三个库，依此类推时，耦合的负面影响就会变得很明显。最糟糕的耦合形式要求用户理解每个耦合的库。耦合也可能降低库的可移植性——即使所有使用的库都是自包含的（参见下面关于使用 <iostream> 库的可疑用法的示例）。
应该肯定使用另一个 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。
