(Details)
The benefits of using components from other libraries include clearer, more understandable, code, reduced development and maintenance costs, and the assurance which comes from using well-known and trusted building blocks.
The costs incurred may include added compilation and runtime costs, and undesirable coupling between components. If the interface to the additional component is complex, using it may make code less readable, and thus actually increase development and maintenance costs.
Example where another boost component should be used: boost::noncopyable (in boost/utility.hpp) has considerable benefits; it simplifies code, improves readability, and signals intent. Costs are low as coupling is limited; it uses no other classes and includes only the generally lightweight headers <boost/config.hpp> and <cstddef>. There are no runtime costs at all. With costs so low and benefits so high, other boost libraries should use boost::noncopyable except in exceptional circumstances.
Example where a standard library component might be used: Providing diagnostic output as a debugging aid can be a nice feature for a library. Yet using Standard Library iostreams for the purpose involves a lot of additional coupling, if iostreams is otherwise unused, and may be a complete waste if the library is used in a GUI or embedded application. It might be better to redesign the boost library so that the user supplies the output mechanism, avoiding marginal use of iostreams.
Example where another boost component should not be used: The boost dir_it library has considerable coupling and runtime costs, not to mention portability issues with unsupported operating systems. While completely appropriate when directory iteration is required, it would not be reasonable for another boost library to use dir_it just to check that a file is available before opening, since Standard Library file open functionality does this at lower cost. Don't use dir_it just for the sake of using a boost library.