Planet
navi homePPSaboutscreenshotsdownloaddevelopmentforum

source: downloads/boost_1_33_1/more/imp_vars.htm @ 18

Last change on this file since 18 was 12, checked in by landauf, 17 years ago

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