3 | | = Boost Library reuse: cost versus benefit trade-offs = #intro |
4 | | |
5 | | A Boost library '''should not''' use libraries |
6 | | other than Boost or the C++ Standard Library. |
7 | | |
8 | | A Boost library '''should''' use other Boost |
9 | | Libraries or the C++ Standard Library, but only when the |
10 | | benefits outweigh the costs. |
11 | | |
12 | | The benefits of using components from other libraries may |
13 | | include clearer, more understandable code, reduced development |
14 | | and maintenance costs, and the assurance which comes from |
15 | | reusing well-known and trusted building blocks. |
16 | | |
17 | | The costs may include undesirable coupling between |
18 | | components, and added compilation and runtime costs. If the |
19 | | interface to the additional component is complex, using it may |
20 | | make code less readable, and thus actually increase development |
21 | | and maintenance costs. |
22 | | |
23 | | Negative effects of coupling become obvious when one library |
24 | | uses a second library which uses a third, and so on. The worst |
25 | | form of coupling requires the user understand each of the |
26 | | coupled libraries. Coupling may also reduce the portability of |
27 | | a library - even in case when all used libraries are |
28 | | self-sufficient (see example of questionable usage of |
29 | | <iostream> library below). |
30 | | |
31 | | '''Example where another boost component should |
32 | | certainly be used:''' boost::noncopyable (in |
33 | | [http://www.boost.org/doc/libs/release/boost/utility.hpp boost/utility.hpp]) |
34 | | has considerable benefits; it simplifies code, improves |
35 | | readability, and signals intent. Costs are low as coupling is |
36 | | limited; noncopyable itself uses no other classes and its |
37 | | header includes only the lightweight headers |
38 | | <boost/config.hpp> and <cstddef>. There are no |
39 | | runtime costs at all. With costs so low and benefits so high, |
40 | | other boost libraries should use boost::noncopyable when the |
41 | | need arises except in exceptional circumstances. |
42 | | |
43 | | '''Example where a standard library component might |
44 | | possibly be used:''' Providing diagnostic output as a |
45 | | debugging aid can be a nice feature for a library. Yet using |
46 | | Standard Library <iostream> can involves a lot of |
47 | | additional cost, particularly if <iostream> is unlikely |
48 | | to be use elsewhere in the application. In certain GUI or |
49 | | embedded applications, coupling to <iostream> would be a |
50 | | disqualification. Consider redesign of the boost library in |
51 | | question so that the user supplies the diagnostic output |
52 | | mechanism. |
53 | | |
54 | | '''Example where another boost component should not be |
55 | | used:''' The boost dir_it library has considerable |
56 | | coupling and runtime costs, not to mention portability issues |
57 | | for unsupported operating systems. While completely appropriate |
58 | | when directory iteration is required, it would not be |
59 | | reasonable for another boost library to use dir_it just to |
60 | | check that a file is available before opening. C++ Standard |
61 | | Library file open functionality does this at lower cost. Don't |
62 | | use dir_it just for the sake of using a boost library. |
63 | | |
64 | | Copyright Beman Dawes 2000. |
| 3 | This has been move back to the [http://www.boost.org/development/reuse.html main site] |