From cbe627ffa5221ae7a9db6d6a686da46e6f0722e4 Mon Sep 17 00:00:00 2001 From: Beman Dawes Date: Wed, 27 Sep 2000 20:57:49 +0000 Subject: [PATCH] Initial commit [SVN r7859] --- library_reuse.htm | 72 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 library_reuse.htm diff --git a/library_reuse.htm b/library_reuse.htm new file mode 100644 index 0000000..8951be8 --- /dev/null +++ b/library_reuse.htm @@ -0,0 +1,72 @@ + + + + + + + +Library Reuse + + + + + + + + + + + + + +
c++boost.gif (8819 bytes)HomeLibrariesPeopleFAQMore
+  +

Library reuse: cost versus benefit trade-offs

+

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

+
+

Revised 17 August 2000

+

 

+

 

+ + + +