diff options
| -rw-r--r-- | more/imp_vars.htm | 211 |
1 files changed, 0 insertions, 211 deletions
diff --git a/more/imp_vars.htm b/more/imp_vars.htm deleted file mode 100644 index 0b6101273b..0000000000 --- a/more/imp_vars.htm +++ /dev/null @@ -1,211 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<html> - -<head> -<meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> -<meta name="GENERATOR" content="Microsoft FrontPage 5.0"> -<meta name="ProgId" content="FrontPage.Editor.Document"> -<title>Boost Implementation Variations</title> -</head> - -<body link="#0000ff" vlink="#800080" bgcolor="#FFFFFF" text="#000000"> - -<table summary="Navigational header" - border="1" bgcolor="#007F7F" cellpadding="2"> - <tr> - <td bgcolor="#FFFFFF"><img src="../boost.png" alt="boost.png (6897 bytes)" width="277" height="86"></td> - <td><a href="../index.htm"><font face="Arial" color="#FFFFFF"><big>Home</big></font></a></td> - <td><a href="../libs/libraries.htm"><font face="Arial" color="#FFFFFF"><big>Libraries</big></font></a></td> - <td><a href="../people/people.htm"><font face="Arial" color="#FFFFFF"><big>People</big></font></a></td> - <td><a href="faq.htm"><font face="Arial" color="#FFFFFF"><big>FAQ</big></font></a></td> - <td><a href="index.htm"><font face="Arial" color="#FFFFFF"><big>More</big></font></a></td> - </tr> -</table> -<h1>Boost Implementation Variations</h1> -<h2>Separation of interface and implementation</h2> -<p>The interface specifications for boost.org library components (as well as for -quality software in general) are conceptually separate from implementations of -those interfaces. This may not be obvious, particularly when a component is -implemented entirely within a header, but this separation of interface and -implementation is always assumed. From the perspective of those concerned with -software design, portability, and standardization, the interface is what is -important, while the implementation is just a detail.</p> -<p>Dietmar Kühl, one of the original boost.org contributors, comments "The -main contribution is the interface, which is augmented with an implementation, -proving that it is possible to implement the corresponding class and providing a -free implementation."</p> - -<h2>Implementation variations</h2> - -<p>There may be a need for multiple implementations of an interface, to -accommodate either platform dependencies or performance tradeoffs. Examples of -platform dependencies include compiler shortcomings, file systems, thread -mechanisms, and graphical user interfaces. The classic example of a performance -tradeoff is a fast implementation which uses a lot of memory versus a slower -implementation which uses less memory.</p> -<p>Boost libraries generally use a <a href="../libs/config/config.htm">configuration -header</a>, boost/config.hpp, to capture compiler and platform -dependencies. Although the use of boost/config.hpp is not required, it is -the preferred approach for simple configuration problems. </p> -<h2>Boost policy</h2> -<p>The Boost policy is to avoid platform dependent variations in interface -specifications, but supply implementations which are usable over a wide range of -platforms and applications. That means boost libraries will use the -techniques below described as appropriate for dealing with platform -dependencies.</p> -<p>The Boost policy toward implementation variations designed to enhance -performance is to avoid them unless the benefits greatly exceed the full -costs. The term "full costs" is intended to include both -tangible costs like extra maintenance, and intangible cost like increased -difficulty in user understanding.</p> - -<h2>Techniques for providing implementation variations</h2> - -<p>Several techniques may be used to provide implementation variations. Each is -appropriate in some situations, and not appropriate in other situations.</p> -<h3>Single general purpose implementation</h3> -<p>The first technique is to simply not provide implementation variation at -all. Instead, provide a single general purpose implementation, and forgo -the increased complexity implied by all other techniques.</p> -<p><b>Appropriate:</b> When it is possible to write a single portable -implementation which has reasonable performance across a wide range of -platforms. Particularly appropriate when alternative implementations differ only -in esoteric ways.</p> -<p><b>Not appropriate:</b> When implementation requires platform specific -features, or when there are multiple implementation possible with widely -differing performance characteristics.</p> -<p>Beman Dawes comments "In design discussions some implementation is often -alleged to be much faster than another, yet a timing test discovers no -significant difference. The lesson is that while algorithmic differences may -affect speed dramatically, coding differences such as changing a class from -virtual to non-virtual members or removing a level of indirection are unlikely -to make any measurable difference unless deep in an inner loop. And even in an -inner loop, modern CPUs often execute such competing code sequences in the -same number of clock cycles! A single general purpose implementation is -often just fine."</p> -<p>Or as Donald Knuth said, "Premature optimization is the root of all -evil." (Computing Surveys, vol 6, #4, p 268).</p> -<h3>Macros</h3> -<p>While the evils of macros are well known, there remain a few cases where -macros are the preferred solution:</p> -<blockquote> - <ul> - <li> Preventing multiple inclusion of headers via #include guards.</li> - <li> Passing minor configuration information from a configuration - header to other files.</li> - </ul> -</blockquote> -<p><b>Appropriate:</b> For small compile-time variations which would -otherwise be costly or confusing to install, use, or maintain. More appropriate -to communicate within and between library components than to communicate with -library users.</p> -<p><b>Not appropriate: </b> If other techniques will do.</p> -<p>To minimize the negative aspects of macros:</p> -<blockquote> - <ul> - <li>Only use macros when they are clearly superior to other - techniques. They should be viewed as a last resort.</li> - <li>Names should be all uppercase, and begin with the namespace name. This - will minimize the chance of name collisions. For example, the #include - guard for a boost header called foobar.h might be named BOOST_FOOBAR_H.</li> - </ul> -</blockquote> -<h3>Separate files</h3> -<p>A library component can have multiple variations, each contained in its own -separate file or files. The files for the most appropriate variation are -copied to the appropriate include or implementation directories at installation -time.</p> -<p>The way to provide this approach in boost libraries is to include specialized -implementations as separate files in separate sub-directories in the .ZIP -distribution file. For example, the structure within the .ZIP distribution file -for a library named foobar which has both default and specialized variations -might look something like:</p> -<blockquote> - <pre>foobar.h // The default header file -foobar.cpp // The default implementation file -readme.txt // Readme explains when to use which files -self_contained/foobar.h // A variation with everything in the header -linux/foobar.cpp // Implementation file to replace the default -win32/foobar.h // Header file to replace the default -win32/foobar.cpp // Implementation file to replace the default</pre> -</blockquote> -<p><b>Appropriate:</b> When different platforms require different -implementations, or when there are major performance differences between -possible implementations. </p> -<p><b>Not appropriate:</b> When it makes sense to use more that one of the -variations in the same installation.</p> -<h3>Separate components</h3> -<p>Rather than have several implementation variations of a single component, -supply several separate components. For example, the Boost library currently -supplies <code>scoped_ptr</code> and <code>shared_ptr</code> classes rather than -a single <code>smart_ptr</code> class parameterized to distinguish between the -two cases. There are several ways to make the component choice:</p> -<blockquote> - <ul> - <li>Hardwired by the programmer during coding.</li> - <li>Chosen by programmer written runtime logic (trading off some extra - space, time, and program complexity for the ability to select the - implementation at run-time.)</li> - </ul> -</blockquote> -<p><b>Appropriate: </b>When the interfaces for the variations diverge, and when -it is reasonably to use more than one of the variations. When run-time selection -of implementation is called for.</p> -<p><b>Not appropriate:</b> When the variations are data type, traits, or -specialization variations which can be better handled by making the component a -template. Also not appropriate when choice of variation is best done by some -setup or installation mechanism outside of the program itself. Thus -usually not appropriate to cope with platform differences.</p> -<p><b>Note:</b> There is a related technique where the interface is specified as -an abstract (pure virtual) base class (or an interface definition language), and -the implementation choice is passed off to some third-party, such as a -dynamic-link library or object-request broker. While that is a powerful -technique, it is way beyond the scope of this discussion.</p> -<h3>Template-based approaches</h3> -<p>Turning a class or function into a template is often an elegant way to cope -with variations. Template-based approaches provide optimal space and time -efficiency in return for constraining the implementation selection to compile -time. </p> -<p>Important template techniques include:</p> -<blockquote> - <ul> - <li>Data type parameterization. This allows a single component to - operate on a variety of data types, and is why templates were originally - invented.</li> - <li>Traits parameterization. If parameterization is complex, bundling - up aspects into a single traits helper class can allow great variation - while hiding messy details. The C++ Standard Library provides - several examples of this idiom, such as <code>iterator_traits<></code> - (24.3.1 lib.iterator.traits) and <tt>char_traits<></tt> (21.2 - lib.char.traits).</li> - <li>Specialization. A template parameter can be used purely for the - purpose of selecting a specialization. For example:</li> - </ul> - <blockquote> - <blockquote> - <pre>SomeClass<fast> my_fast_object; // fast and small are empty classes -SomeClass<small> my_small_object; // used just to select specialization</pre> - </blockquote> - </blockquote> -</blockquote> -<p><b>Appropriate: </b>When the need for variation is due to data type or -traits, or is performance related like selecting among several algorithms, and -when a program might reasonably use more than one of the variations.</p> -<p><b>Not appropriate:</b> When the interfaces for variations are -different, or when choice of variation is best done by some mechanism outside of -the program itself. Thus usually not appropriate to cope with platform -differences.</p> -<hr> -<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> - -<p>© Copyright Beman Dawes 2001</p> - -<p>Distributed under the Boost Software License, Version 1.0. (See - accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy - at <a href= - "http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>) -</p> - -</body> - -</html>
\ No newline at end of file |