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。
