(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.
--
- - - -