Changes between Version 2 and Version 3 of Guidelines/Reuse


Ignore:
Timestamp:
Aug 18, 2010, 10:56:38 PM (12 years ago)
Author:
Daniel James
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Guidelines/Reuse

    v2 v3  
    1 [[PageOutline]]
     1= Boost Library reuse: cost versus benefit trade-offs =
    22
    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.
     3This has been move back to the [http://www.boost.org/development/reuse.html main site]