Changes between Initial Version and Version 1 of Guidelines/Reuse

Timestamp:

Feb 14, 2010, 12:06:54 PM (13 years ago)

Author:

Daniel James

Comment:

--

Guidelines/Reuse

@@ +1 @@
+[[PageOutline]]
+
+= Boost Library reuse: cost versus benefit trade-offs = #intro
+
+A Boost library '''should not''' use libraries
+other than Boost or the C++ Standard Library.
+
+A Boost library '''should''' use other Boost
+Libraries or the C++ Standard Library, but only when the
+benefits outweigh the costs.
+
+The benefits of using components from other libraries may
+include clearer, more understandable code, reduced development
+and maintenance costs, and the assurance which comes from
+reusing well-known and trusted building blocks.
+
+The costs may include undesirable coupling between
+components, and added compilation and runtime costs. If the
+interface to the additional component is complex, using it may
+make code less readable, and thus actually increase development
+and maintenance costs.
+
+Negative effects of coupling become obvious when one library
+uses a second library which uses a third, and so on. The worst
+form of coupling requires the user understand each of the
+coupled libraries. Coupling may also reduce the portability of
+a library - even in case when all used libraries are
+self-sufficient (see example of questionable usage of
+<iostream> library below).
+
+'''Example where another boost component should
+certainly be used:''' boost::noncopyable (in 
+[http://www.boost.org/doc/libs/release/boost/utility.hpp boost/utility.hpp])
+has considerable benefits; it simplifies code, improves
+readability, and signals intent. Costs are low as coupling is
+limited; noncopyable itself uses no other classes and its
+header includes only the 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 when the
+need arises except in exceptional circumstances.
+
+'''Example where a standard library component might
+possibly be used:''' Providing diagnostic output as a
+debugging aid can be a nice feature for a library. Yet using
+Standard Library <iostream> can involves a lot of
+additional cost, particularly if <iostream> is unlikely
+to be use elsewhere in the application. In certain GUI or
+embedded applications, coupling to <iostream> would be a
+disqualification. Consider redesign of the boost library in
+question so that the user supplies the diagnostic output
+mechanism.
+
+'''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
+for 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. C++ Standard
+Library file open functionality does this at lower cost. Don't
+use dir_it just for the sake of using a boost library.