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。
