| [29] | 1 | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
|---|
| 2 | <html> |
|---|
| 3 | |
|---|
| 4 | <head> |
|---|
| 5 | <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> |
|---|
| 6 | <meta name="GENERATOR" content="Microsoft FrontPage 5.0"> |
|---|
| 7 | <meta name="ProgId" content="FrontPage.Editor.Document"> |
|---|
| 8 | <title>Boost Implementation Variations</title> |
|---|
| 9 | </head> |
|---|
| 10 | |
|---|
| 11 | <body link="#0000ff" vlink="#800080" bgcolor="#FFFFFF" text="#000000"> |
|---|
| 12 | |
|---|
| 13 | <table summary="Navigational header" |
|---|
| 14 | border="1" bgcolor="#007F7F" cellpadding="2"> |
|---|
| 15 | <tr> |
|---|
| 16 | <td bgcolor="#FFFFFF"><img src="../boost.png" alt="boost.png (6897 bytes)" width="277" height="86"></td> |
|---|
| 17 | <td><a href="../index.htm"><font face="Arial" color="#FFFFFF"><big>Home</big></font></a></td> |
|---|
| 18 | <td><a href="../libs/libraries.htm"><font face="Arial" color="#FFFFFF"><big>Libraries</big></font></a></td> |
|---|
| 19 | <td><a href="../people/people.htm"><font face="Arial" color="#FFFFFF"><big>People</big></font></a></td> |
|---|
| 20 | <td><a href="faq.htm"><font face="Arial" color="#FFFFFF"><big>FAQ</big></font></a></td> |
|---|
| 21 | <td><a href="index.htm"><font face="Arial" color="#FFFFFF"><big>More</big></font></a></td> |
|---|
| 22 | </tr> |
|---|
| 23 | </table> |
|---|
| 24 | <h1>Boost Implementation Variations</h1> |
|---|
| 25 | <h2>Separation of interface and implementation</h2> |
|---|
| 26 | <p>The interface specifications for boost.org library components (as well as for |
|---|
| 27 | quality software in general) are conceptually separate from implementations of |
|---|
| 28 | those interfaces. This may not be obvious, particularly when a component is |
|---|
| 29 | implemented entirely within a header, but this separation of interface and |
|---|
| 30 | implementation is always assumed. From the perspective of those concerned with |
|---|
| 31 | software design, portability, and standardization, the interface is what is |
|---|
| 32 | important, while the implementation is just a detail.</p> |
|---|
| 33 | <p>Dietmar Kühl, one of the original boost.org contributors, comments "The |
|---|
| 34 | main contribution is the interface, which is augmented with an implementation, |
|---|
| 35 | proving that it is possible to implement the corresponding class and providing a |
|---|
| 36 | free implementation."</p> |
|---|
| 37 | |
|---|
| 38 | <h2>Implementation variations</h2> |
|---|
| 39 | |
|---|
| 40 | <p>There may be a need for multiple implementations of an interface, to |
|---|
| 41 | accommodate either platform dependencies or performance tradeoffs. Examples of |
|---|
| 42 | platform dependencies include compiler shortcomings, file systems, thread |
|---|
| 43 | mechanisms, and graphical user interfaces. The classic example of a performance |
|---|
| 44 | tradeoff is a fast implementation which uses a lot of memory versus a slower |
|---|
| 45 | implementation which uses less memory.</p> |
|---|
| 46 | <p>Boost libraries generally use a <a href="../libs/config/config.htm">configuration |
|---|
| 47 | header</a>, boost/config.hpp, to capture compiler and platform |
|---|
| 48 | dependencies. Although the use of boost/config.hpp is not required, it is |
|---|
| 49 | the preferred approach for simple configuration problems. </p> |
|---|
| 50 | <h2>Boost policy</h2> |
|---|
| 51 | <p>The Boost policy is to avoid platform dependent variations in interface |
|---|
| 52 | specifications, but supply implementations which are usable over a wide range of |
|---|
| 53 | platforms and applications. That means boost libraries will use the |
|---|
| 54 | techniques below described as appropriate for dealing with platform |
|---|
| 55 | dependencies.</p> |
|---|
| 56 | <p>The Boost policy toward implementation variations designed to enhance |
|---|
| 57 | performance is to avoid them unless the benefits greatly exceed the full |
|---|
| 58 | costs. The term "full costs" is intended to include both |
|---|
| 59 | tangible costs like extra maintenance, and intangible cost like increased |
|---|
| 60 | difficulty in user understanding.</p> |
|---|
| 61 | |
|---|
| 62 | <h2>Techniques for providing implementation variations</h2> |
|---|
| 63 | |
|---|
| 64 | <p>Several techniques may be used to provide implementation variations. Each is |
|---|
| 65 | appropriate in some situations, and not appropriate in other situations.</p> |
|---|
| 66 | <h3>Single general purpose implementation</h3> |
|---|
| 67 | <p>The first technique is to simply not provide implementation variation at |
|---|
| 68 | all. Instead, provide a single general purpose implementation, and forgo |
|---|
| 69 | the increased complexity implied by all other techniques.</p> |
|---|
| 70 | <p><b>Appropriate:</b> When it is possible to write a single portable |
|---|
| 71 | implementation which has reasonable performance across a wide range of |
|---|
| 72 | platforms. Particularly appropriate when alternative implementations differ only |
|---|
| 73 | in esoteric ways.</p> |
|---|
| 74 | <p><b>Not appropriate:</b> When implementation requires platform specific |
|---|
| 75 | features, or when there are multiple implementation possible with widely |
|---|
| 76 | differing performance characteristics.</p> |
|---|
| 77 | <p>Beman Dawes comments "In design discussions some implementation is often |
|---|
| 78 | alleged to be much faster than another, yet a timing test discovers no |
|---|
| 79 | significant difference. The lesson is that while algorithmic differences may |
|---|
| 80 | affect speed dramatically, coding differences such as changing a class from |
|---|
| 81 | virtual to non-virtual members or removing a level of indirection are unlikely |
|---|
| 82 | to make any measurable difference unless deep in an inner loop. And even in an |
|---|
| 83 | inner loop, modern CPUs often execute such competing code sequences in the |
|---|
| 84 | same number of clock cycles! A single general purpose implementation is |
|---|
| 85 | often just fine."</p> |
|---|
| 86 | <p>Or as Donald Knuth said, "Premature optimization is the root of all |
|---|
| 87 | evil." (Computing Surveys, vol 6, #4, p 268).</p> |
|---|
| 88 | <h3>Macros</h3> |
|---|
| 89 | <p>While the evils of macros are well known, there remain a few cases where |
|---|
| 90 | macros are the preferred solution:</p> |
|---|
| 91 | <blockquote> |
|---|
| 92 | <ul> |
|---|
| 93 | <li> Preventing multiple inclusion of headers via #include guards.</li> |
|---|
| 94 | <li> Passing minor configuration information from a configuration |
|---|
| 95 | header to other files.</li> |
|---|
| 96 | </ul> |
|---|
| 97 | </blockquote> |
|---|
| 98 | <p><b>Appropriate:</b> For small compile-time variations which would |
|---|
| 99 | otherwise be costly or confusing to install, use, or maintain. More appropriate |
|---|
| 100 | to communicate within and between library components than to communicate with |
|---|
| 101 | library users.</p> |
|---|
| 102 | <p><b>Not appropriate: </b> If other techniques will do.</p> |
|---|
| 103 | <p>To minimize the negative aspects of macros:</p> |
|---|
| 104 | <blockquote> |
|---|
| 105 | <ul> |
|---|
| 106 | <li>Only use macros when they are clearly superior to other |
|---|
| 107 | techniques. They should be viewed as a last resort.</li> |
|---|
| 108 | <li>Names should be all uppercase, and begin with the namespace name. This |
|---|
| 109 | will minimize the chance of name collisions. For example, the #include |
|---|
| 110 | guard for a boost header called foobar.h might be named BOOST_FOOBAR_H.</li> |
|---|
| 111 | </ul> |
|---|
| 112 | </blockquote> |
|---|
| 113 | <h3>Separate files</h3> |
|---|
| 114 | <p>A library component can have multiple variations, each contained in its own |
|---|
| 115 | separate file or files. The files for the most appropriate variation are |
|---|
| 116 | copied to the appropriate include or implementation directories at installation |
|---|
| 117 | time.</p> |
|---|
| 118 | <p>The way to provide this approach in boost libraries is to include specialized |
|---|
| 119 | implementations as separate files in separate sub-directories in the .ZIP |
|---|
| 120 | distribution file. For example, the structure within the .ZIP distribution file |
|---|
| 121 | for a library named foobar which has both default and specialized variations |
|---|
| 122 | might look something like:</p> |
|---|
| 123 | <blockquote> |
|---|
| 124 | <pre>foobar.h // The default header file |
|---|
| 125 | foobar.cpp // The default implementation file |
|---|
| 126 | readme.txt // Readme explains when to use which files |
|---|
| 127 | self_contained/foobar.h // A variation with everything in the header |
|---|
| 128 | linux/foobar.cpp // Implementation file to replace the default |
|---|
| 129 | win32/foobar.h // Header file to replace the default |
|---|
| 130 | win32/foobar.cpp // Implementation file to replace the default</pre> |
|---|
| 131 | </blockquote> |
|---|
| 132 | <p><b>Appropriate:</b> When different platforms require different |
|---|
| 133 | implementations, or when there are major performance differences between |
|---|
| 134 | possible implementations. </p> |
|---|
| 135 | <p><b>Not appropriate:</b> When it makes sense to use more that one of the |
|---|
| 136 | variations in the same installation.</p> |
|---|
| 137 | <h3>Separate components</h3> |
|---|
| 138 | <p>Rather than have several implementation variations of a single component, |
|---|
| 139 | supply several separate components. For example, the Boost library currently |
|---|
| 140 | supplies <code>scoped_ptr</code> and <code>shared_ptr</code> classes rather than |
|---|
| 141 | a single <code>smart_ptr</code> class parameterized to distinguish between the |
|---|
| 142 | two cases. There are several ways to make the component choice:</p> |
|---|
| 143 | <blockquote> |
|---|
| 144 | <ul> |
|---|
| 145 | <li>Hardwired by the programmer during coding.</li> |
|---|
| 146 | <li>Chosen by programmer written runtime logic (trading off some extra |
|---|
| 147 | space, time, and program complexity for the ability to select the |
|---|
| 148 | implementation at run-time.)</li> |
|---|
| 149 | </ul> |
|---|
| 150 | </blockquote> |
|---|
| 151 | <p><b>Appropriate: </b>When the interfaces for the variations diverge, and when |
|---|
| 152 | it is reasonably to use more than one of the variations. When run-time selection |
|---|
| 153 | of implementation is called for.</p> |
|---|
| 154 | <p><b>Not appropriate:</b> When the variations are data type, traits, or |
|---|
| 155 | specialization variations which can be better handled by making the component a |
|---|
| 156 | template. Also not appropriate when choice of variation is best done by some |
|---|
| 157 | setup or installation mechanism outside of the program itself. Thus |
|---|
| 158 | usually not appropriate to cope with platform differences.</p> |
|---|
| 159 | <p><b>Note:</b> There is a related technique where the interface is specified as |
|---|
| 160 | an abstract (pure virtual) base class (or an interface definition language), and |
|---|
| 161 | the implementation choice is passed off to some third-party, such as a |
|---|
| 162 | dynamic-link library or object-request broker. While that is a powerful |
|---|
| 163 | technique, it is way beyond the scope of this discussion.</p> |
|---|
| 164 | <h3>Template-based approaches</h3> |
|---|
| 165 | <p>Turning a class or function into a template is often an elegant way to cope |
|---|
| 166 | with variations. Template-based approaches provide optimal space and time |
|---|
| 167 | efficiency in return for constraining the implementation selection to compile |
|---|
| 168 | time. </p> |
|---|
| 169 | <p>Important template techniques include:</p> |
|---|
| 170 | <blockquote> |
|---|
| 171 | <ul> |
|---|
| 172 | <li>Data type parameterization. This allows a single component to |
|---|
| 173 | operate on a variety of data types, and is why templates were originally |
|---|
| 174 | invented.</li> |
|---|
| 175 | <li>Traits parameterization. If parameterization is complex, bundling |
|---|
| 176 | up aspects into a single traits helper class can allow great variation |
|---|
| 177 | while hiding messy details. The C++ Standard Library provides |
|---|
| 178 | several examples of this idiom, such as <code>iterator_traits<></code> |
|---|
| 179 | (24.3.1 lib.iterator.traits) and <tt>char_traits<></tt> (21.2 |
|---|
| 180 | lib.char.traits).</li> |
|---|
| 181 | <li>Specialization. A template parameter can be used purely for the |
|---|
| 182 | purpose of selecting a specialization. For example:</li> |
|---|
| 183 | </ul> |
|---|
| 184 | <blockquote> |
|---|
| 185 | <blockquote> |
|---|
| 186 | <pre>SomeClass<fast> my_fast_object; // fast and small are empty classes |
|---|
| 187 | SomeClass<small> my_small_object; // used just to select specialization</pre> |
|---|
| 188 | </blockquote> |
|---|
| 189 | </blockquote> |
|---|
| 190 | </blockquote> |
|---|
| 191 | <p><b>Appropriate: </b>When the need for variation is due to data type or |
|---|
| 192 | traits, or is performance related like selecting among several algorithms, and |
|---|
| 193 | when a program might reasonably use more than one of the variations.</p> |
|---|
| 194 | <p><b>Not appropriate:</b> When the interfaces for variations are |
|---|
| 195 | different, or when choice of variation is best done by some mechanism outside of |
|---|
| 196 | the program itself. Thus usually not appropriate to cope with platform |
|---|
| 197 | differences.</p> |
|---|
| 198 | <hr> |
|---|
| 199 | <p>Revised <!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan -->02 October, 2003<!--webbot bot="Timestamp" endspan i-checksum="38549" --></p> |
|---|
| 200 | |
|---|
| 201 | <p>© Copyright Beman Dawes 2001</p> |
|---|
| 202 | |
|---|
| 203 | <p>Distributed under the Boost Software License, Version 1.0. (See |
|---|
| 204 | accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy |
|---|
| 205 | at <a href= |
|---|
| 206 | "http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>) |
|---|
| 207 | </p> |
|---|
| 208 | |
|---|
| 209 | </body> |
|---|
| 210 | |
|---|
| 211 | </html> |
|---|
