From cfd127be486a3a0200ba6025a053501ab9e90b32 Mon Sep 17 00:00:00 2001 From: Ronald Garcia Date: Thu, 15 Nov 2007 12:50:48 +0000 Subject: [PATCH 01/10] John Torjo is reviewing the X-files. [SVN r41104] --- formal_review_schedule.html | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/formal_review_schedule.html b/formal_review_schedule.html index 028b5af..acd36ca 100644 --- a/formal_review_schedule.html +++ b/formal_review_schedule.html @@ -95,8 +95,8 @@ authors address issues raised in the formal review.

Tobias Schwinger Boost Sandbox Vault - Needed - - + John Torjo + January 14, 2007 - January 18, 2007 @@ -105,7 +105,7 @@ authors address issues raised in the formal review.

Boost Sandbox Vault John Torjo - - + December 3, 2007 - December 7, 2007 @@ -113,8 +113,8 @@ authors address issues raised in the formal review.

Tobias Schwinger Boost Sandbox Vault - Needed - - + John Torjo + December 17, 2007 - December 21, 2007 From 5ded4548dd4da69c2d19b39c9aa590557c43e121 Mon Sep 17 00:00:00 2001 From: Ronald Garcia Date: Fri, 16 Nov 2007 12:37:08 +0000 Subject: [PATCH 02/10] Added flyweignt and Unordered Containers. [SVN r41144] --- formal_review_schedule.html | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/formal_review_schedule.html b/formal_review_schedule.html index acd36ca..02f7c0f 100644 --- a/formal_review_schedule.html +++ b/formal_review_schedule.html @@ -96,7 +96,7 @@ authors address issues raised in the formal review.

Boost Sandbox Vault John Torjo - January 14, 2007 - January 18, 2007 + January 14, 2008 - January 18, 2008 @@ -143,7 +143,32 @@ authors address issues raised in the formal review.

- + + Flyweight + Joaquín Mª López Muñoz + + Boost Sandbox Vault + Needed + - + + + Unordered Containers + Daniel James + Boost Sandbox Vault + Needed + - + + + From 4d4c4614480b9e5a211b1a009941e38abee5534e Mon Sep 17 00:00:00 2001 From: Ronald Garcia Date: Fri, 16 Nov 2007 13:22:09 +0000 Subject: [PATCH 03/10] Initial Revision. [SVN r41145] --- report-nov-2007.html | 423 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 423 insertions(+) create mode 100644 report-nov-2007.html diff --git a/report-nov-2007.html b/report-nov-2007.html new file mode 100644 index 0000000..7d30787 --- /dev/null +++ b/report-nov-2007.html @@ -0,0 +1,423 @@ + + + + + + +Review Wizard Status Report for November 2007 + + + +
+

Review Wizard Status Report for November 2007

+
+

News

+
+
November 7, 2007 - Exception Library Accepted
+
Announcement: http://lists.boost.org/boost-users/2007/11/31912.php
+
+

We need experienced review managers. Please take a look at the list +of libraries in need of managers and check out their descriptions. In +general review managers are active boost participants or library +contributors. If you can serve as review manager for any of them, +email Ron Garcia or John Phillips, "garcia at cs dot indiana dot edu" +and "jphillip at capital dot edu" respectively.

+

A link to this report will be posted to www.boost.org. +If you would like us to make any modifications or additions to this +report before we do that, please email Ron or John.

+

If you're library author and plan on submitting a library for review +in the next 3-6 months, send Ron or John a short description of your +library and we'll add it to the Libraries Under Construction below. +We know that there are many libraries that are near completion, but we +have hard time keeping track all of them. Please keep us informed +about your progress.

+
+
+

Review Queue

+
    +
  • Finite State Machines
    • +
  • Floating Point Utilities
    • +
  • Switch
    • +
  • Property Map (fast-track)
    • +
  • Graph (fast-track)
    • +
  • Forward (fast-track)
    • +
  • Singleton (fast-track)
    • +
  • Factory (fast-track)
    • +
  • Lexer
    • +
  • Thread-Safe Signals
    • +
  • Logging
    • +
  • Flyweight
    • +
  • Unordered Containers
    • +
+
+
+

Finite State Machines

+ +++ + + + + + + + + + +
Author:Andrey Semashev
Review Manager:Martin Vuille
Download:Boost Sandbox Vault
Description:

The Boost.FSM library is an implementation of FSM (stands for +Finite State Machine) programming concept. The main goals of the +library are:

+
    +
  • Simplicity. It should be very simple to create state machines using +this library.
    • +
  • Performance. The state machine infrastructure should not be +very time and memory-consuming in order to be applicable in +more use cases.
    • +
  • Extensibility. A developer may want to add more states to an +existing state machine. A developer should also be able to +specify additional transitions and events for the machine with +minimum modifications to the existing code.
    • +
+
+
+
+

Floating Point Utilities

+ +++ + + + + + + + + + +
Author:Johan RÃ¥de
Review Manager:Need Volunteer
Download:Boost Sandbox Vault
Description:

The Floating Point Utilities library contains the following:

+
    +
  • Floating point number classification functions: fpclassify, isfinite, +isinf, isnan, isnormal (Follows TR1)
    • +
  • Sign bit functions: signbit, copysign, changesign (Follows TR1)
    • +
  • Facets that format and parse infinity and NaN according to the C99 +standard (These can be used for portable handling of infinity and NaN +in text streams).
    • +
+
+
+
+

Switch

+ +++ + + + + + + + + + +
Author:Steven Watanabe
Review Manager:Need Volunteer
Download:Boost Sandbox Vault
Description:The built in C/C++ switch statement is very efficient. Unfortunately, +unlike a chained if/else construct there is no easy way to use it when +the number of cases depends on a template parameter. The Switch library +addresses this issue.
+
+
+

Property Map (fast-track)

+ +++ + + + + + + + + + +
Author:Andrew Sutton
Review Manager:Jeremy Siek
Download:http://svn.boost.org/svn/boost/sandbox/graph-v2
Description:

A number of additions and modifications to the Property Map Library, +including:

+
    +
  • A constant-valued property map, useful for naturally unweighted +graphs.
    • +
  • A noop-writing property map, useful when you have to provide an +argument, but just don't care about the output.
    • +
  • See +ChangeLog +for details.
    • +
+
+
+
+

Graph (fast-track)

+ +++ + + + + + + + + + +
Author:Andrew Sutton
Review Manager:Jeremy Siek
Download:http://svn.boost.org/svn/boost/sandbox/graph-v2
Description:

A number of additions and modifications to the Graph Library, +including:

+
    +
  • Two new graph classes (undirected and directed) which are intended +to make the library more approachable for new developers
    • +
  • A suite of graph measures including degree and closeness +centrality, mean geodesic distance, eccentricity, and clustering +coefficients.
    • +
  • An algorithm for visiting all cycles in a directed graph (Tiernan's +from 1970ish). It works for undirected graphs too, but reports cycles +twice (one for each direction).
    • +
  • An algorithm for visiting all the cliques a graph (Bron&Kerbosch). +Works for both directed and undirected.
    • +
  • Derived graph measures radius and diameter (from eccentricity) and +girth and circumference (from Tiernan), and clique number (from +Bron&Kerbosch).
    • +
  • An exterior_property class that helps hides some of the weirdness +with exterior properties.
    • +
  • runtime and compile-time tests for the new algorithms.
    • +
  • a substantial amount of documentation
    • +
  • Graph cores, implemented by David Gleich (@Stanford University)
    • +
  • Deterministic graph generators - capable of creating or inducing +specific types of graphs over a vertex set (e.g., star graph, wheel +graph, prism graph, etc). There are several other specific types that +could be added to this, but I haven't had the time just yet.
    • +
+
+
+
+

Forward (fast-track)

+ +++ + + + + + + + + + +
Author:Tobias Schwinger
Review Manager:John Torjo
Download:http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=X-Files
Description:A brute-force solution to the forwarding problem.
+
+
+

Singleton (fast-track)

+ +++ + + + + + + + + + +
Author:Tobias Schwinger
Review Manager:John Torjo
Download:http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=X-Files
Description:Three thread-safe Singleton templates with an +easy-to-use interface.
+
+
+

Factory (fast-track)

+ +++ + + + + + + + + + +
Author:Tobias Schwinger
Review Manager:John Torjo
Download:http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=X-Files
Description:Generic factories.
+
+
+

Lexer

+ +++ + + + + + + + + + +
Author:Ben Hanson
Review Manager:Need Volunteer
Download:http://boost-consulting.com/vault/index.php?action=downloadfile&filename=boost.lexer.zip&directory=Strings%20-%20Text%20Processing&
Description:A programmable lexical analyser generator inspired by 'flex'. +Like flex, it is programmed by the use of regular expressions +and outputs a state machine as a number of DFAs utilising +equivalence classes for compression.
+
+
+

Thread-Safe Signals

+ +++ + + + + + + + + + +
Author:Frank Hess
Review Manager:Need Volunteer
Download:http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directory=thread_safe_signals
Description:A thread-safe implementation of Boost.signals that +has some interface changes to accommodate thread safety, mostly with +respect to automatic connection management.
+
+
+

Logging

+ +++ + + + + + + + + + +
Author:John Torjo
Review Manager:Need Volunteer
Download:http://torjo.com/log2/
Description:Used properly, logging is a very powerful tool. Besides aiding +debugging/testing, it can also show you how your application is +used. The Boost Logging Library allows just for that, supporting +a lot of scenarios, ranging from very simple (dumping all to one +destination), to very complex (multiple logs, some enabled/some +not, levels, etc). It features a very simple and flexible +interface, efficient filtering of messages, thread-safety, +formatters and destinations, easy manipulation of logs, finding +the best logger/filter classes based on your application's +needs, you can define your own macros and much more!
+
+
+

Flyweight

+ +++ + + + + + + + + + +
Author:Joaquín M López Muñoz
Review Manager:Need Volunteer
Download:http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=flyweight.zip&directory=Patterns
Description:Flyweights are small-sized handle classes granting +constant access to shared common data, thus allowing for the +management of large amounts of entities within reasonable memory +limits. Boost.Flyweight makes it easy to use this common +programming idiom by providing the class template flyweight<T>, +which acts as a drop-in replacement for const T.
+
+
+

Unordered Containers

+ +++ + + + + + + + + + +
Author:Daniel James
Review Manager:Need Volunteer
Download:http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=unordered.zip&directory=Containers
Description:An implementation of the unordered containers specified +in TR1, with most of the changes from the recent draft standards.
+
+
+
+

Libraries under development

+
+

Dataflow

+ +++ + + + + + + + +
Author:Stjepan Rajko
Description:The Dataflow library provides generic support for data +producers, consumers, and connections between the two. It also +provides layers for several specific dataflow mechanisms, namely +Boost.Signals, VTK data/display pipelines, and plain +pointers. The Dataflow library came out of the Signal Network +GSoC project, mentored by Doug Gregor.
Status:I am polishing the Dataflow library for submission, and am expecting +to add it to the review queue in the next couple of months. +I am currently ironing out some faults in the design of the library, +filling in missing features, and testing it on / adapting it to +different dataflow mechanisms (currently VTK and soon +Boost.Iostreams). As soon as I'm pretty sure that things are going +the right way, I'll submit this to the review queue while I do the +finishing touches.
+
+
+

Constrained Value

+ +++ + + + + + + + + + +
Author:Robert Kawulak
Download:

http://rk.go.pl/f/constrained_value.zip

+

http://rk.go.pl/r/constrained_value (Documentation)

+
Description:The Constrained Value library contains class templates +useful for creating constrained objects. The simplest example +of a constrained object is hour. The only valid values for an hour +within a day are integers from the range [0, 23]. With this library, +you can create a variable which behaves exactly like int, but does +not allow for assignment of values which do not belong to the +allowed range. The library doesn't focus only on constrained +objects that hold a value belonging to a specified range (i.e., +bounded objects). Virtually any constraint can be imposed using +appropriate predicate. You can specify what happens in case of +assignment of an invalid value, e.g. an exception may be thrown or +the value may be adjusted to meet the constraint criterions.
Status:I'm planning to finish it in 1-2 months.
+

Please let us know of any libraries you are currently +developing that you intend to submit for review.

+
+
+
+ + From 6d53ef5575aa1494da047a5e44dcb050e9fc2c3d Mon Sep 17 00:00:00 2001 From: Ronald Garcia Date: Fri, 16 Nov 2007 13:23:41 +0000 Subject: [PATCH 04/10] Review Wizard Report. [SVN r41146] --- formal_review_schedule.html | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/formal_review_schedule.html b/formal_review_schedule.html index 02f7c0f..d7baf90 100644 --- a/formal_review_schedule.html +++ b/formal_review_schedule.html @@ -184,6 +184,14 @@ authors address issues raised in the formal review.

Result + + Review Wizard Status Report + + Ronald Garcia + 2007 November 16 + Report + + Exception Emil Dotchevski From d98c6bbe34d905a00f8856b76f6314d3e17eb920 Mon Sep 17 00:00:00 2001 From: Daniel James Date: Fri, 16 Nov 2007 18:46:36 +0000 Subject: [PATCH 05/10] Move the bug and feature request pages to the new site. Refs #1259. Fixes #1369. [SVN r41154] --- bugs.htm | 118 ------------------------------------ requesting_new_features.htm | 56 ----------------- 2 files changed, 174 deletions(-) delete mode 100644 bugs.htm delete mode 100644 requesting_new_features.htm diff --git a/bugs.htm b/bugs.htm deleted file mode 100644 index 6d07c54..0000000 --- a/bugs.htm +++ /dev/null @@ -1,118 +0,0 @@ - - - - - - - - - Bugs - - - - - - - - - - - - - - - - -
- boost.png (6897 bytes)Home - Libraries - PeopleFAQMore
- -

What to do about Boost bugs

- -
    - -
  1. Make sure the bug isn't already fixed in the latest sources. The most - recent version of everything on the Boost web site is available from - the boost public - CVS repository.
    -
    -
    2. -
  2. If you are a Boost user, or a Boost developer that doesn't have a CVS - write access:
    -
    -
      -
    1. Submit a bug report to either - boost-users list, - boost mailing - list, or our bug - tracking facility; submitting it to either of the mailing - lists is a preferred way - because many of the Boost developers read the - lists on a daily basis, this way you are likely to get a quicker response, - and the discussions that often arise there from (possible) bug reports are - quite interesting and educational as well;
      -
      -
      2. -
    2. If you have a proposed patch to the code, post it along with your bug - report, preferably in the unified diffs format (cvs diff -du); - if you can, send a patch relative to the current CVS state. A canonical -example of creating a patch file follows (let's assume that you've found -a bug in the file intentional_bug.hpp:
      -
      -
        -
      1. Download the latest version of intentional_bug.hpp from CVS.
        2. -
      2. Make sure that the bug is still present in the code.
        3. -
      3. Copy the file intentional_bug.hpp to a file called intentional_bug.hpp.orig.
        4. -
      4. Apply your changes to intentional_bug.hpp.
        5. -
      5. Run "diff -du intentional_bug.hpp.orig intentional_bug.hpp > intentional_bug.hpp.patch" from the command prompt.
        6. -
      6. Submit the patch file together with an explanation of the bug -and the proposed fix; and don't forget to include the word patch or bug -in the subject if you're submitting to the boost mailing list.
        -
        -
        7. -
      - -
      3. - -
    -
    3. -
  3. If you are a Boost developer, and you have a CVS write access:
    -
    -
      -
    1. If the bug is trivial (e.g. misspelled name, missed typename, - etc.), and you are willing to make a fix, either make your changes locally - and contact the library author(s)/maintainer(s) about it, or go ahead and - check the fix into CVS, but post a notification about it to the - boost mailing - list (if the author is not very active on the list, you also might want - to consider cc'ing him as well);
      -
      -
      2. -
    2. If the bug is non-trivial, and/or you don't have the time and resources to fix it, - submit a bug report (see p. 2 above); chances are that the maintainer(s) - will respond promptly and take care of the problem;
      -
      -
      3. -
    3. Otherwise, create a temporary branch in CVS, make your changes there, and - ask the library author(s)/maintainer(s) to review them; if they are ok with - the new code, either you or they can integrate the fixes into the main - trunk.
      4. -
    -
    4. -
- -
-

Revised 18 January, 2002 -

- -

© Copyright Aleksey Gurtovoy -2002

-

Distributed under the Boost Software License, Version 1.0. -(See accompanying file LICENSE_1_0.txt or -copy at www.boost.org/LICENSE_1_0.txt) -

- -
- - - diff --git a/requesting_new_features.htm b/requesting_new_features.htm deleted file mode 100644 index 5787ca4..0000000 --- a/requesting_new_features.htm +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - - -Requesting New Features - - - - - - - - - - - - - -
- boost.png (6897 bytes)Home - Libraries - PeopleFAQMore
-

Requesting new features for Boost libraries

-

If you have an idea for a feature or improvement to an existing Boost library -- go ahead and post it to either -boost-users list -or boost mailing list -(if you are posting for the first time, please read our -discussion policy -before you actually post).

-

You can also use our -feature request tracking facility at SourceForge, but experience has shown -that posting to either of the mailing lists is usually a more effective way to -get attention of boost developers.

-

If your proposal has its merits, it's very likely that it will generate a -constructive discussion that might actually result in (sometimes substantial) -improvement of the library - and your name being put on the library's - -Acknowledgements section!

-
-

Revised 26 November, 2003 -

- -

© Copyright Aleksey Gurtovoy -2002

-

Distributed under the Boost Software License, Version 1.0. -(See accompanying file LICENSE_1_0.txt or -copy at www.boost.org/LICENSE_1_0.txt) -

- - - - \ No newline at end of file From 09b9373d596ca64a06483d45bcbc9db8b4c3e136 Mon Sep 17 00:00:00 2001 From: Daniel James Date: Sun, 18 Nov 2007 20:18:04 +0000 Subject: [PATCH 06/10] Move the 'implementation variations' page to the new site. Fixes #1355. [SVN r41210] --- imp_vars.htm | 211 --------------------------------------------------- 1 file changed, 211 deletions(-) delete mode 100644 imp_vars.htm diff --git a/imp_vars.htm b/imp_vars.htm deleted file mode 100644 index 0b61012..0000000 --- a/imp_vars.htm +++ /dev/null @@ -1,211 +0,0 @@ - - - - - - - -Boost Implementation Variations - - - - - - - - - - - - - -
boost.png (6897 bytes)HomeLibrariesPeopleFAQMore
-

Boost Implementation Variations

-

Separation of interface and implementation

-

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.

-

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."

- -

Implementation variations

- -

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.

-

Boost libraries generally use a configuration -header, 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.  

-

Boost policy

-

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.

-

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.

- -

Techniques for providing implementation variations

- -

Several techniques may be used to provide implementation variations. Each is -appropriate in some situations, and not appropriate in other situations.

-

Single general purpose implementation

-

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.

-

Appropriate:  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.

-

Not appropriate: When implementation requires platform specific -features, or when there are multiple implementation possible with widely -differing performance characteristics.

-

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."

-

Or as Donald Knuth said, "Premature optimization is the root of all -evil." (Computing Surveys, vol 6, #4, p 268).

-

Macros

-

While the evils of macros are well known, there remain a few cases where -macros are the preferred solution:

-
-
    -
  •  Preventing multiple inclusion of headers via #include guards.
    • -
  •  Passing minor configuration information from a configuration - header to other files.
    • -
-
-

Appropriate:  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.

-

Not appropriate:  If other techniques will do.

-

To minimize the negative aspects of macros:

-
-
    -
  • Only use macros when they are clearly superior to other - techniques.  They should be viewed as a last resort.
    • -
  • 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.
    • -
-
-

Separate files

-

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.

-

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:

-
- 
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
-
-

Appropriate:  When different platforms require different -implementations, or when there are major performance differences between -possible implementations. 

-

Not appropriate:  When it makes sense to use more that one of the -variations in the same installation.

-

Separate components

-

Rather than have several implementation variations of a single component, -supply several separate components. For example, the Boost library currently -supplies scoped_ptr and shared_ptr classes rather than -a single smart_ptr class parameterized to distinguish between the -two cases.  There are several ways to make the component choice:

-
-
    -
  • Hardwired by the programmer during coding.
    • -
  • 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.)
    • -
-
-

Appropriate: 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.

-

Not appropriate: 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.

-

Note: 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.

-

Template-based approaches

-

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. 

-

Important template techniques include:

-
-
    -
  • Data type parameterization.  This allows a single component to - operate on a variety of data types, and is why templates were originally - invented.
    • -
  • 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 iterator_traits<> - (24.3.1 lib.iterator.traits) and char_traits<> (21.2 - lib.char.traits).
    • -
  • Specialization.  A template parameter can be used purely for the - purpose of selecting a specialization. For example:
    • -
-
-
- 
SomeClass<fast>  my_fast_object;  // fast and small are empty classes
-SomeClass<small> my_small_object; // used just to select specialization
-
-
-
-

Appropriate: 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.

-

Not appropriate:  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.

-
-

Revised 02 October, 2003

- -

© Copyright Beman Dawes 2001

- -

Distributed under the Boost Software License, Version 1.0. (See - accompanying file LICENSE_1_0.txt or copy - at http://www.boost.org/LICENSE_1_0.txt) -

- - - - \ No newline at end of file From eaf201d7b0da99b1234a15b49a6e79ac98ef82d6 Mon Sep 17 00:00:00 2001 From: Ronald Garcia Date: Mon, 19 Nov 2007 13:28:00 +0000 Subject: [PATCH 07/10] A bunch of review volunteers. [SVN r41224] --- formal_review_schedule.html | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/formal_review_schedule.html b/formal_review_schedule.html index d7baf90..a8ab8a3 100644 --- a/formal_review_schedule.html +++ b/formal_review_schedule.html @@ -68,7 +68,7 @@ authors address issues raised in the formal review.

Steven Watanabe Boost Sandbox Vault - Needed + Stejpan Rajko - @@ -122,7 +122,7 @@ authors address issues raised in the formal review.

Ben Hanson Boost Sandbox Vault - Needed + Hartmut Kaiser - @@ -139,7 +139,7 @@ authors address issues raised in the formal review.

Logging John Torjo http://torjo.com/log2/ - Needed + Gennadiy Rozental - @@ -148,7 +148,7 @@ authors address issues raised in the formal review.

Joaquín Mª López Muñoz Boost Sandbox Vault - Needed + Ion Gaztañaga - @@ -156,7 +156,7 @@ authors address issues raised in the formal review.

Unordered Containers Daniel James Boost Sandbox Vault - Needed + Ion Gaztañaga - From b578706889721f921e3fd80ad9b857b6c05790ca Mon Sep 17 00:00:00 2001 From: Ronald Garcia Date: Mon, 19 Nov 2007 14:01:34 +0000 Subject: [PATCH 08/10] Added boost.range update [SVN r41225] --- formal_review_schedule.html | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/formal_review_schedule.html b/formal_review_schedule.html index a8ab8a3..3b7133b 100644 --- a/formal_review_schedule.html +++ b/formal_review_schedule.html @@ -160,10 +160,18 @@ authors address issues raised in the formal review.

- + + Boost.Range (Update) + Neil Groves + + Needed + - + + - - diff --git a/BoostCon07_session_call.html b/BoostCon07_session_call.html deleted file mode 100644 index f905cea..0000000 --- a/BoostCon07_session_call.html +++ /dev/null @@ -1,12 +0,0 @@ - - - - - -The BoostCon site is -live! - - - - -