Initial Content Conversion

This is based off of revision 56094d2c9f510f5ee4f1ffd4eb6b73788aaa62d7
of https://github.com/boostorg/website/.

URL of exact commit is: 56094d2c9f

common/footer-banners.html

@@ -0,0 +1,13 @@
+---
+title: 
+copyright: 
+revised: 
+--- 
+[XHTML 1.0](https://validator.w3.org/check?uri=referer)
+
+
+[CSS](https://jigsaw.w3.org/css-validator/check/referer)
+
+
+[OSI
+ Certified](https://opensource.org/docs/definition.php)

common/footer-license.html

@@ -0,0 +1,6 @@
+---
+title: 
+copyright: 
+revised: 
+--- 
+Distributed under the [Boost Software License, Version 1.0](/LICENSE_1_0.txt).

common/heading-doc.html

@@ -0,0 +1,5 @@
+---
+title: 
+copyright: 
+revised: 
+--- 

common/heading.html

@@ -0,0 +1,16 @@
+---
+title: 
+copyright: 
+revised: 
+---
+
+
+[Boost C++ Libraries
+Boost
+C++ Libraries](/)
+=============================================
+...one of the most highly
+ regarded and expertly designed C++ library projects in the
+ world. — [Herb Sutter](http://www.gotw.ca/) and [Andrei
+ Alexandrescu](http://en.wikipedia.org/wiki/Andrei_Alexandrescu), [C++
+ Coding Standards](http://safari.awprofessional.com/?XmlId=0321113586)

common/menu-boost.html

@@ -0,0 +1,23 @@
+---
+title: 
+copyright: 
+revised: 
+--- #### [Introduction >](/users/index.html)
+
+
+* [Download >](/users/download/)
+* [News >](/users/news/)
+* [Version History
+ >](/users/history/)
+* [License >](/users/license.html)
+* [People >](/users/people.html)
+* [Memoriam >](/users/memoriam.html)
+* [Bibliography
+ >](/users/bibliography.html)
+* [Who's Using Boost
+ >](/users/uses.html)
+* [FAQ >](/users/faq.html)
+* [How Boost Started >](/users/proposal.pdf)
+* [Index >](/map.html)
+
+

common/menu-community.html

@@ -0,0 +1,42 @@
+---
+title: 
+copyright: 
+revised: 
+--- #### [Community >](/community/index.html)
+
+
+* [Discussion Groups >](/community/groups.html)
+* [Discussion Policy >](/community/policy.html)
+* [C++ >](/community/cpp.html)
+	+ [Committee Meetings
+	 >](/community/committee.html)
+	+ [Official Library Maintainer Program>](/community/official_library_maintainer_program.html)
+	+ [Generic Progamming
+	 Techniques >](/community/generic_programming.html)
+	+ [Error and Exception
+	 Handling >](/community/error_handling.html)
+	+ [Exception-Safety in
+	 Generic Components >](/community/exception_safety.html)
+	+ [Counted Body Techniques
+	 >](/community/counted_body.html)
+	+ [Implementation Variations
+	 >](/community/implementation_variations.html)
+	+ [Feature Model
+	 Diagrams >](/community/feature_model_diagrams.html)
+* [Acknowledgements >](/community/acknowledgements.html)
+* [Mailing Lists >](/community/groups.html)
+* [Moderators >](/community/moderators.html)
+* [Steering
+ Committee >](https://sites.google.com/a/boost.org/steering/)
+* [Requesting a New Feature
+ >](/community/requests.html)
+* [Reviews >](/community/reviews.html)
+	+ [Schedule >](/community/review_schedule.html)
+* [Sandbox >](/community/sandbox.html)
+* [IRC >](/community/irc.html)
+* [Google Summer of Code >](/community/gsoc.html)
+	+ [2006 Overview
+	 >](/community/gsoc_2006_boost_overview.html)
+* [C++Now >](http://cppnow.org)
+
+

common/menu-development.html

@@ -0,0 +1,45 @@
+---
+title: 
+copyright: 
+revised: 
+--- #### [Development >](/development/index.html)
+
+
+* [GitHub >](https://github.com/boostorg)
+* [Submissions >](/development/submissions.html)
+* [Reporting and Fixing
+ Bugs>](/development/bugs.html)
+* [Open Pull
+ Requests Report>](/development/pull_requests.php)
+* [Testing >](/development/testing.html)
+	+ [Master Summary
+	 >](/development/tests/master/developer/summary.html)
+	+ [Master Issues
+	 >](/development/tests/master/developer/issues.html)
+	+ [Develop
+	 Summary >](/development/tests/develop/developer/summary.html)
+	+ [Develop
+	 Issues >](/development/tests/develop/developer/issues.html)
+	+ [Running
+	 Regression Tests >](/development/running_regression_tests.html)
+* [Requirements and Guidelines
+ >](/development/requirements.html)
+	+ [Test policy >](/development/test.html)
+	+ [Header policy >](/development/header.html)
+	+ [Separate Source
+	 >](/development/separate_compilation.html)
+	+ [Library Reuse >](/development/reuse.html)
+	+ [Coding
+	 Guidelines for Integral Constant Expressions >](/development/int_const_guidelines.html)
+	+ [Library
+	 Metadata >](/development/library_metadata.html)
+* ### Website
+
+
+	+ [Updating
+	 >](/development/website_updating.html)
+	+ [Exemplar >](/development/exemplar.html)
+	+ [Design FAQ >](/development/design_faq.html)
+	+ [Self Check >](/development/webcheck/index.html)
+
+

common/menu-welcome.html

@@ -0,0 +1,16 @@
+---
+title: 
+copyright: 
+revised: 
+--- #### [Welcome >](/)
+
+
+* [Getting Started >](/doc/libs/release/more/getting_started/index.html)
+* [Download >](/users/download/)
+* [Libraries >](/doc/libs/)
+* [Mailing Lists >](/community/groups.html)
+* [Reporting and
+ Fixing Bugs>](/development/bugs.html)
+* [Wiki>](https://github.com/boostorg/wiki/wiki/)
+
+

common/sidebar-boost.html

@@ -0,0 +1,11 @@
+---
+title: 
+copyright: 
+revised: 
+--- 
+* 
+* 
+* 
+* 
+* 
+

common/sidebar-common.html

@@ -0,0 +1,7 @@
+---
+title: 
+copyright: 
+revised: 
+---
+
+

common/sidebar-community.html

@@ -0,0 +1,11 @@
+---
+title: 
+copyright: 
+revised: 
+--- 
+* 
+* 
+* 
+* 
+* 
+

common/sidebar-development.html

@@ -0,0 +1,11 @@
+---
+title: 
+copyright: 
+revised: 
+--- 
+* 
+* 
+* 
+* 
+* 
+

common/sidebar-doc.html

@@ -0,0 +1,11 @@
+---
+title: 
+copyright: 
+revised: 
+--- 
+* 
+* 
+* 
+* 
+* 
+

common/sidebar-donate.html

@@ -0,0 +1,7 @@
+---
+title: 
+copyright: 
+revised: 
+---
+[![Donate to Boost](https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif)](/donate)
+

common/sidebar-get-boost.html

@@ -0,0 +1,7 @@
+---
+title: 
+copyright: 
+revised: 
+--- 
+[Get Boost](/users/download/)
+-----------------------------

common/sidebar-search.html

@@ -0,0 +1,16 @@
+---
+title: 
+copyright: 
+revised: 
+--- 
+
+
+ (function() {
+ var cx = '011577717147771266991:jigzgqluebe';
+ var gcse = document.createElement('script');
+ gcse.type = 'text/javascript';
+ gcse.async = true;
+ gcse.src = 'https://cse.google.com/cse.js?cx=' + cx;
+ var s = document.getElementsByTagName('script')[0];
+ s.parentNode.insertBefore(gcse, s);
+ })();

common/sidebar-support.html

@@ -0,0 +1,11 @@
+---
+title: 
+copyright: 
+revised: 
+--- 
+* 
+* 
+* 
+* 
+* 
+

common/sidebar-welcome.html

@@ -0,0 +1,11 @@
+---
+title: 
+copyright: 
+revised: 
+--- 
+* 
+* 
+* 
+* 
+* 
+

community/_template_.html

@@ -0,0 +1,24 @@
+---
+title: Boost C++ Libraries
+copyright: Rene Rivera 2007.
+revised: 
+---
+
+
+Boost C++ Libraries
+
+
+
+Boost C++ Libraries
+===================
+
+{stuff}
+
+
+
+
+
+
+
+
+

community/acknowledgements.html

@@ -0,0 +1,84 @@
+---
+title: Acknowledgements
+copyright: David Abrahams 2011.
+revised: 2010-05-06 07:05:24 -0400
+---
+Acknowledgements
+
+
+/\*<![CDATA[\*/
+ a.c2 {font-style: italic}
+ strong.c1 {font-style: italic}
+ /\*]]>\*/
+ 
+
+
+Acknowledgements
+================
+
+A list of some people and organizations who contribute to
+ keeping Boost running.
+
+
+Technical Resources
+-------------------
+Web Hosting, Mailing Lists, and Trac Administration
+
+Hosting resources for the Boost mailing lists, our web
+ server, our [wiki
+ and old bug tracker](http://svn.boost.org/trac/boost), are donated by [Rackspace](https://rackspace.com/).
+
+
+Maintenance, IT support, and general care-and-feeding of
+ the resources is donated by [Ciere Consulting](https://ciere.com/)
+SSL Certificate
+
+Our wildcard SSL Certificate was generously donated by
+ the good folks at [Ciere Consulting](https://ciere.com/).
+Rendering for producing Boost documentation in PDF
+ format
+
+Thanks to [RenderX.inc](http://www.renderx.com) for free use of their XEP
+ rendering program, vital for the production of the very
+ popular PDF versions of many Boost manuals written in
+ Quickbook, BoostBook, etc.
+
+Testing
+-------
+
+
+The compiler status tables have been prepared with resources
+ donated by a number of individuals, educational institutions,
+ and companies. Boost would like to thank them for their
+ support. Some of the organizations helping include:
+
+
+* ![Borland](../gfx/borland_logo.gif)  
+
+[Borland](http://www.borland.com/)
+* ![intel](../gfx/intel_logo.gif)  
+
+[Intel
+ Corporation](http://www.intel.com/software/products)
+* ![Microsoft](../gfx/ms_logo.gif)  
+
+[Microsoft](http://msdn.microsoft.com/visualc/)
+* [Hewlett-Packard
+ Company](http://www.hp.com/)
+* [Lawrence Berkeley National
+ Laboratory](http://www.lbl.gov)
+* [Open Systems
+ Laboratory, Indiana University](http://www.osl.iu.edu/)
+Note, however, that Boost does not endorse any product or
+ service, nor does Boost guarantee that some or all of its
+ libraries work with any of the products or services mentioned
+ above.
+
+
+
+
+
+
+
+
+

community/blom_libraries/boost_function.html

@@ -0,0 +1,47 @@
+---
+title: Boost.Function Official Maintainer
+copyright: Alex Olivas 2015.
+revised: 
+---
+
+
+Boost.Function Official Maintainer
+
+
+/\*<![CDATA[\*/
+ body {font-family: sans-serif;}
+ /\*]]>\*/
+ 
+
+
+Boost.Function Official Maintainer
+==================================
+
+![IceCube South Pole Neutrino Observatory](logos/IceCube_horizontal2.jpg)
+Boost.Function
+--------------
+
+
+[The IceCube
+ Collaboration](http://www.icecube.wisc.edu/) is responsible for maintenance of the
+ Boost.Function library.
+
+
+The team consists of:
+
+
+* Alex Olivas (PoC) - U. Maryland, College Park
+* David Schultz - U. Wisconsin, Madison
+* David Delvethal - U. Wisconsin, Madison
+* Hans Dembinski - U. Delaware
+* Jakob van Santen - DESY - Zeuthen
+
+
+
+
+
+Revised 14 September 2015
+
+&copy: 
+
+

community/committee.html

@@ -0,0 +1,182 @@
+---
+title: C++ Committee Meetings
+copyright: 
+revised: 
+---
+
+
+C++ Committee Meetings
+
+
+ body {font-family: sans-serif;}
+ 
+
+
+C++ Committee Meeting FAQ for Boost Members
+===========================================
+
+
+**Who can attend C++ Committee meetings?**
+ Members of PL22.16 (the INCITS/ANSI committee) or of WG21 (ISO)
+ member country committee ("national body" in ISO-speak).
+ [INCITS](http://www.ncits.org/) has broadened PL22.16
+ membership requirements so anyone can join, regardless of
+ nationality or employer.
+
+
+Meeting attendance requirements are tighter than in earlier 
+ times, due to changes in INCITS and ISO rules. Anyone who is an 
+ employee of a PL22.16 member organization can attend, as can 
+ anyone who is a member of one of the national body groups such as 
+ the [BSI](http://en.wikipedia.org/wiki/British_Standards).
+
+
+Any non-member who would like to visit should check with the 
+ PL22.16 chair or head of their national delegation. The Boosters 
+ who are active on the committee can help smooth the way. Contact 
+ the [Boost
+ developer list](https://lists.boost.org/mailman/listinfo.cgi/boost) for more information.
+
+
+**When and where is the next meeting?** There
+ are three meetings a year. Two are usually in North
+ America, and one is usually outside North
+ America. See a general [list of
+ meeting locations and dates](http://www.open-std.org/jtc1/sc22/wg21/docs/meetings). Detailed information about a
+ particular meeting, including hotel information, is usually
+ provided in a paper appearing in one of [mailings](#Mailing) for the prior meeting. If there isn't a
+ link to it on the [Meetings](http://www.open-std.org/jtc1/sc22/wg21/docs/meetings)
+ web page, you will have to go to the committee's [Papers](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/)
+ page and search a bit.
+
+
+**Is there a fee for attending meetings?** No,
+ but there can be a lot of incidental expenses like travel,
+ lodging, and meals.
+
+
+**What is the schedule?** The meetings start at 
+ 9:00AM on Monday, and 8:30AM other days, unless otherwise 
+ announced. It is best to arrive a half-hour early to grab a good 
+ seat, some coffee, tea, or donuts, and to say hello to people.
+
+
+Until the next
+ standard ships most meetings are running through Saturday, 
+ although some end on Friday. The last day, the meeting is generally over 
+ much earlier than on other days. Because the last day's formal meeting is for formal votes
+ only, it is primarily of interest only to actual committee
+ members.
+
+
+Sometimes there are evening technical sessions; the details
+ aren't usually available until the Monday morning meeting.
+ There may be a reception one evening, and, yes, significant
+ others are invited. Again, details usually become available
+ Monday morning.
+
+
+**What actually happens at the meetings?**
+ Monday morning an hour or two is spent in full committee on
+ administrivia, and then the committee breaks up into working
+ groups (Core, Library, and Enhancements). The full committee
+ also gets together later in the week to hear working group
+ progress reports.
+
+
+The working groups are where most technical activities take
+ place. Each active issue that appears on an issues list is
+ discussed, as are papers from the mailing. Most issues are
+ non-controversial and disposed of in a few minutes. Technical
+ discussions are often led by long-term committee members, often
+ referring to past decisions or longstanding working group
+ practice. Sometimes a controversy erupts. It takes first-time
+ attendees awhile to understand the discussions and how
+ decisions are actually made. The working group chairperson
+ moderates.
+
+
+Sometimes straw polls are taken. In a straw poll anyone
+ attending can vote, in contrast to the formal votes taken by
+ the full committee, where only voting members can vote.
+
+
+Lunch break is an hour and a half. Informal subgroups often
+ lunch together; a lot of technical problems are discussed or
+ actually solved at lunch, or later at dinner. In many ways
+ these discussions involving only a few people are the most
+ interesting. Sometimes during the regular meetings, a working
+ group chair will break off a sub-group to tackle a difficult
+ problem.
+
+
+**Do I have to stay at the main hotel?** No,
+ and committee members on tight budgets often stay at other,
+ cheaper, hotels. (The main hotels are usually chosen because
+ they have large meeting rooms available, and thus tend to be
+ pricey.) The advantage of staying at the main hotel is that it
+ is then easier to participate in the off-line discussions, which
+ can be at least as interesting as what actually happens in the
+ scheduled meetings.
+
+
+**What do people wear at meetings?** Programmer
+ casual. No neckties to be seen.
+
+
+**What should I bring to a meeting?** It is almost 
+ essential to have a laptop computer along. There is a meeting wiki and 
+ there is internet connectivity. Wireless
+ connectivity has become the norm.
+
+
+**What should I do to prepare for a meeting?**
+ It is helpful to have downloaded the mailing or individual
+ papers for the meeting, and read any papers you are interested
+ in. Familiarize yourself with the issues lists if you haven't
+ done so already. Decide which of the working groups you want to
+ attend.
+
+
+**What is a "Paper"?** An electronic document containing
+ issues, proposals, or anything else the committee is interested
+ in. Very little gets discussed at a meeting, much less acted
+ upon, unless it is presented in a paper. [Papers are
+ available](http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/) to anyone. Papers don't just appear randomly;
+ they become available four (lately six) times a year, before
+ and after each meeting. Committee members often refer to a
+ paper by saying what mailing it was in: "See the pre-Redmond
+ mailing."
+
+
+**What is a "Mailing"?** A mailing is the set of papers
+ prepared four to six times a year before and after each
+ meeting, or between meetings. It is physically just a [.zip or
+ .gz](http://www.open-std.org/jtc1/sc22/wg21/docs/mailings/) archive of all the papers for a meeting. Although the
+ mailing's archive file itself is only available to committee
+ members and technical experts, the contents (except copies of
+ the standard) are available to the general public as individual
+ papers. The ways of ISO are inscrutable.
+
+
+**What is a "Reflector"?** The committee's
+ mailing lists are called "reflectors". There are a number of
+ them; "all", "core", "lib", and "ext" are the main ones. As a
+ courtesy, Boost technical experts can be added to committee
+ reflectors at the request of a committee member.
+
+
+
+---
+
+
+© Copyright Beman Dawes, 2002, 2006, 2007, 2009, 2010
+
+
+Distributed under the Boost Software License, Version 1.0. See
+ [www.boost.org/LICENSE\_1\_0.txt](https://www.boost.org/LICENSE_1_0.txt)
+
+
+Revised
+ 18 January 2010
+

community/counted_body.html

@@ -0,0 +1,677 @@
+---
+title: Counted Body Techniques
+copyright: Kevlin Henney 1998-1999.
+revised: 
+---
+
+
+Counted Body Techniques
+
+
+
+Counted Body Techniques
+=======================
+
+[Kevlin Henney](/users/people/kevlin_henney.html)  
+
+ ([kevlin@curbralan.com](mailto:kevlin@curbralan.com))
+
+
+Reference counting techniques? Nothing new, you might think.
+ Every good C++ text that takes you to an intermediate or
+ advanced level will introduce the concept. It has been explored
+ with such thoroughness in the past that you might be forgiven
+ for thinking that everything that can be said has been said.
+ Well, let's start from first principles and see if we can
+ unearth something new....
+
+
+And then there were none...
+---------------------------
+
+
+The principle behind reference counting is to keep a running
+ usage count of an object so that when it falls to zero we know
+ the object is unused. This is normally used to simplify the
+ memory management for dynamically allocated objects: keep a
+ count of the number of references held to that object and, on
+ zero, delete the object.
+
+
+How to keep a track of the number of users of an object?
+ Well, normal pointers are quite dumb, and so an extra level of
+ indirection is required to manage the count. This is
+ essentially the PROXY pattern described in *Design
+ Patterns* [Gamma, Helm, Johnson & Vlissides,
+ Addison-Wesley, ISBN 0-201-63361-2]. The intent is given as
+> 
+> *Provide a surrogate or placeholder for another object
+>  to control access to it.*
+> 
+> 
+> 
+
+
+Coplien [*Advanced C++ Programming Styles and Idioms*,
+ Addison-Wesley, ISBN 0-201-56365-7] defines a set of idioms
+ related to this essential separation of a handle and a body
+ part. The *Taligent Guide to Designing Programs*
+ [Addison-Wesley, ISBN 0-201-40888-0] identifies a number of
+ specific categories for proxies (aka surrogates). Broadly
+ speaking they fall into two general categories:
+
+
+* *Hidden*: The handle is the object of interest,
+ hiding the body itself. The functionality of the handle is
+ obtained by delegation to the body, and the user of the
+ handle is unaware of the body. Reference counted strings
+ offer a transparent optimisation. The body is shared between
+ copies of a string until such a time as a change is needed,
+ at which point a copy is made. Such a COPY ON WRITE pattern
+ (a specialization of LAZY EVALUATION) requires the use of a
+ hidden reference counted body.
+* *Explicit*: Here the body is of interest and the
+ handle merely provides intelligence for its access and
+ housekeeping. In C++ this is often implemented as the SMART
+ POINTER idiom. One such application is that of reference-counted smart pointers that collaborate to keep a count of an
+ object, deleting it when the count falls to zero.
+
+
+Attached vs detached
+--------------------
+
+
+For reference counted smart pointers there are two places
+ the count can exist, resulting in two different patterns, both
+ outlined in *Software Patterns* [Coplien, SIGS, ISBN
+ 0-884842-50-X]:
+
+
+* COUNTED BODY or ATTACHED COUNTED HANDLE/BODY places the
+ count within the object being counted. The benefits are that
+ countability is a part of the object being counted, and that
+ reference counting does not require an additional object. The
+ drawbacks are clearly that this is intrusive, and that the
+ space for the reference count is wasted when the object is
+ not heap-based. Therefore the reference counting ties you to
+ a particular implementation and style of use.
+* DETACHED COUNTED HANDLE/BODY places the count outside the
+ object being counted, such that they are handled together.
+ The clear benefit of this is that this technique is
+ completely unintrusive, with all of the intelligence and
+ support apparatus in the smart pointer, and therefore can be
+ used on classes created independently of the reference
+ counted pointer. The main disadvantage is that frequent use
+ of this can lead to a proliferation of small objects, i.e.
+ the counter, being created on the heap.
+
+
+Even with this simple analysis, it seems that the DETACHED
+ COUNTED HANDLE/BODY approach is ahead. Indeed, with the
+ increasing use of templates this is often the favourite, and is
+ the principle behind the common - but not standard -
+ `counted_ptr`. *[The Boost name is [`shared_ptr`](/doc/libs/release/libs/smart_ptr/shared_ptr.htm)
+ rather than `counted_ptr`.]*
+
+
+A common implementation of COUNTED BODY is to provide the
+ counting mechanism in a base class that the counted type is
+ derived from. Either that, or the reference counting mechanism
+ is provided anew for each class that needs it. Both of these
+ approaches are unsatisfactory because they are quite closed,
+ coupling a class into a particular framework. Added to this the
+ non-cohesiveness of having the count lying dormant in a
+ non-counted object, and you get the feeling that excepting its
+ use in widespread object models such as COM and CORBA the
+ COUNTED BODY approach is perhaps only of use in specialized
+ situations.
+
+
+A requirements based approach
+-----------------------------
+
+
+It is the question of openness that convinced me to revisit
+ the problems with the COUNTED BODY idiom. Yes, there is a
+ certain degree of intrusion expected when using this idiom, but
+ is there anyway to minimize this and decouple the choice of
+ counting mechanism from the smart pointer type used?
+
+
+In recent years the most instructive body of code and
+ specification for constructing open general purpose components
+ has been the Stepanov and Lee's STL (Standard Template
+ Library), now part of the C++ standard library. The STL
+ approach makes extensive use of compile time polymorphism based
+ on well defined operational requirements for types. For
+ instance, each container, contained and iterator type is
+ defined by the operations that should be performable on an
+ object of that type, often with annotations describing
+ additional constraints. Compile time polymorphism, as its name
+ suggests, resolves functions at compile time based on function
+ name and argument usage, i.e. overloading. This is less
+ intrusive, although less easily diagnosed if incorrect, than
+ runtime polymorphism that is based on types, names and function
+ signatures.
+
+
+This requirements based approach can be applied to reference
+ counting. The operations we need for a type to be
+ *Countable* are loosely:
+
+
+* An `acquire` operation that registers interest
+ in a *Countable* object.
+* A `release` operation unregisters interest in
+ a *Countable* object.
+* An `acquired` query that returns whether or
+ not a *Countable* object is currently acquired.
+* A `dispose` operation that is responsible for
+ disposing of an object that is no longer acquired.
+
+
+Note that the count is deduced as a part of the abstract
+ state of this type, and is not mentioned or defined in any
+ other way. The openness of this approach derives in part from
+ the use of global functions, meaning that no particular member
+ functions are implied; a perfect way to wrap up an existing
+ counted body class without modifying the class itself. The
+ other aspect of openness comes from a more precise
+ specification of the operations.
+
+
+For a type to be *Countable* it must satisfy the
+ following requirements, where `ptr` is a non-null
+ pointer to a single object (i.e. not an array) of the type, and
+ *`#function`* indicates number of calls to
+ `*function(*ptr*)*`:
+
+|  |  |  |
+| --- | --- | --- |
+| *Expression* | *Return type* | *Semantics and notes* |
+| `acquire(ptr)` | no requirement | *post*: `acquired(ptr)` |
+| `release(ptr)` | no requirement | *pre*: `acquired(ptr)`
+*post*: `acquired(ptr) == #acquire -
+ #release` |
+| `acquired(ptr)` | convertible to `bool` | *return*: `#acquire > #release` |
+| `dispose(ptr, ptr)` | no requirement | *pre*: `!acquired(ptr)`
+*post*: `*ptr` no longer usable |
+
+
+Note that the two arguments to `dispose` are to
+ support selection of the appropriate type-safe version of the
+ function to be called. In the general case the intent is that
+ the first argument determines the type to be deleted, and would
+ typically be templated, while the second selects which template
+ to use, e.g. by conforming to a specific base class.
+
+
+In addition the following requirements must also be
+ satisfied, where `null` is a null pointer to the
+ *Countable* type:
+
+|  |  |  |
+| --- | --- | --- |
+| *Expression* | *Return type* | *Semantics and notes* |
+| `acquire(null)` | no requirement | *action*: none |
+| `release(null)` | no requirement | *action*: none |
+| `acquired(null)` | convertible to `bool` | *return*: `false` |
+| `dispose(null, null)` | no requirement | *action*: none |
+
+
+Note that there are no requirements on these functions in
+ terms of exceptions thrown or not thrown, except that if
+ exceptions are thrown the functions themselves should be
+ exception-safe.
+
+
+Getting smart
+-------------
+
+
+Given the *Countable* requirements for a type, it is
+ possible to define a generic smart pointer type that uses them
+ for reference counting:
+```
+
+template<typename countable\_type>
+class countable\_ptr
+{
+public: // construction and destruction
+
+    explicit countable\_ptr(countable\_type \*);
+    countable\_ptr(const countable\_ptr &);
+    ~countable\_ptr();
+
+public: // access
+
+    countable\_type \*operator->() const;
+    countable\_type &operator\*() const;
+    countable\_type \*get() const;
+
+public: // modification
+
+    countable\_ptr &clear();
+    countable\_ptr &assign(countable\_type \*);
+    countable\_ptr &assign(const countable\_ptr &);
+    countable\_ptr &operator=(const countable\_ptr &);
+
+private: // representation
+
+    countable\_type \*body;
+
+};
+
+```
+
+The interface to this class has been kept intentionally
+ simple, e.g. member templates and `throw` specs have
+ been omitted, for exposition. The majority of the functions are
+ quite simple in implementation, relying very much on the
+ `assign` member as a keystone function:
+```
+
+template<typename countable\_type>
+countable\_ptr<countable\_type>::countable\_ptr(countable\_type \*initial)
+  : body(initial)
+{
+    acquire(body);
+}
+
+template<typename countable\_type>
+countable\_ptr<countable\_type>::countable\_ptr(const countable\_ptr &other)
+  : body(other.body)
+{
+    acquire(body);
+}
+
+template<typename countable\_type>
+countable\_ptr<countable\_type>::~countable\_ptr()
+{
+    clear();
+}
+
+template<typename countable\_type>
+countable\_type \*countable\_ptr<countable\_type>::operator->() const
+{
+    return body;
+}
+
+template<typename countable\_type>
+countable\_type &countable\_ptr<countable\_type>::operator\*() const
+{
+    return \*body;
+}
+
+template<typename countable\_type>
+countable\_type \*countable\_ptr<countable\_type>::get() const
+{
+    return body;
+}
+
+template<typename countable\_type>
+countable\_ptr<countable\_type> &countable\_ptr<countable\_type>::clear()
+{
+    return assign(0);
+}
+
+template<typename countable\_type>
+countable\_ptr<countable\_type> &countable\_ptr<countable\_type>::assign(countable\_type \*rhs)
+{
+    // set to rhs (uses Copy Before Release idiom which is self assignment safe)
+    acquire(rhs);
+    countable\_type \*old\_body = body;
+    body = rhs;
+
+    // tidy up
+    release(old\_body);
+    if(!acquired(old\_body))
+    {
+        dispose(old\_body, old\_body);
+    }
+
+    return \*this;
+}
+
+template<typename countable\_type>
+countable\_ptr<countable\_type> &countable\_ptr<countable\_type>::assign(const countable\_ptr &rhs)
+{
+    return assign(rhs.body);
+}
+
+template<typename countable\_type>
+countable\_ptr<countable\_type> &countable\_ptr<countable\_type>::operator=(const countable\_ptr &rhs)
+{
+    return assign(rhs);
+}
+
+```
+
+Public accountability
+---------------------
+
+
+Conformance to the requirements means that a type can be
+ used with `countable_ptr`. Here is an implementation
+ mix-in class (*mix-imp*) that confers countability on its
+ derived classes through member functions. This class can be
+ used as a class adaptor:
+```
+
+class countability
+{
+public: // manipulation
+
+    void acquire() const;
+    void release() const;
+    size\_t acquired() const;
+
+protected: // construction and destruction
+
+    countability();
+    ~countability();
+
+private: // representation
+
+    mutable size\_t count;
+
+private: // prevention
+
+    countability(const countability &);
+    countability &operator=(const countability &);
+
+};
+
+```
+
+Notice that the manipulation functions are
+ `const` and that the `count` member
+ itself is `mutable`. This is because countability is
+ not a part of an object's abstract state: memory management
+ does not depend on the `const`-ness or otherwise of
+ an object. I won't include the definitions of the member
+ functions here as you can probably guess them: increment,
+ decrement, and return the current count, respectively for the
+ manipulation functions. In a multithreaded environment, you
+ should ensure that such read and write operations are
+ atomic.
+
+
+So how do we make this class *Countable*? A simple set
+ of forwarding functions does the job:
+```
+
+void acquire(const countability \*ptr)
+{
+    if(ptr)
+    {
+        ptr->acquire();
+    }
+}
+
+void release(const countability \*ptr)
+{
+    if(ptr)
+    {
+        ptr->release();
+    }
+}
+
+size\_t acquired(const countability \*ptr)
+{
+    return ptr ? ptr->acquired() : 0;
+}
+
+template<class countability\_derived>
+void dispose(const countability\_derived \*ptr, const countability \*)
+{
+    delete ptr;
+}
+
+```
+
+Any type that now derives from `countability` may
+ now be used with `countable_ptr`:
+```
+
+class example : public countability
+{
+    ...
+};
+
+void simple()
+{
+    countable\_ptr<example> ptr(new example);
+    countable\_ptr<example> qtr(ptr);
+    ptr.clear(); // set ptr to point to null
+}   // allocated object deleted when qtr destructs
+
+```
+
+Runtime mixin
+-------------
+
+
+The challenge is to apply COUNTED BODY in a non-intrusive
+ fashion, such that there is no overhead when an object is not
+ counted. What we would like to do is confer this capability on
+ a per object rather than on a per class basis. Effectively we
+ are after *Countability* on any object, i.e. anything
+ pointed to by a `void *`! It goes without saying
+ that `void` is perhaps the least committed of any
+ type.
+
+
+The forces to resolve this are quite interesting, to say
+ the least. Interesting, but not insurmountable. Given that the
+ class of a runtime object cannot change dynamically in any well
+ defined manner, and the layout of the object must be fixed, we
+ have to find a new place and time to add the counting state.
+ The fact that this must be added only on heap creation suggests
+ the following solution:
+```
+
+struct countable\_new;
+extern const countable\_new countable;
+
+void \*operator new(size\_t, const countable\_new &);
+void operator delete(void \*, const countable\_new &);
+
+```
+
+We have overloaded `operator new` with a dummy
+ argument to distinguish it from the regular global
+ `operator new`. This is comparable to the use of the
+ `std::nothrow_t` type and `std::nothrow`
+ object in the standard library. The placement `operator
+ delete` is there to perform any tidy up in the event of
+ failed construction. Note that this is not yet supported on all
+ that many compilers.
+
+
+The result of a `new` expression using
+ `countable` is an object allocated on the heap that
+ has a header block that holds the count, i.e. we have extended
+ the object by prefixing it. We can provide a couple of features
+ in an anonymous namespace (not shown) in the implementation
+ file for supporting the count and its access from a raw
+ pointer:
+```
+
+struct count
+{
+    size\_t value;
+};
+
+count \*header(const void \*ptr)
+{
+    return const\_cast<count \*>(static\_cast<const count \*>(ptr) - 1);
+}
+
+```
+
+An important constraint to observe here is the alignment of
+ `count` should be such that it is suitably aligned
+ for any type. For the definition shown this will be the case on
+ almost all platforms. However, you may need to add a padding
+ member for those that don't, e.g. using an anonymous
+ `union` to coalign `count` and the most
+ aligned type. Unfortunately, there is no portable way of
+ specifying this such that the minimum alignment is also
+ observed - this is a common problem when specifying your own
+ allocators that do not directly use the results of either
+ `new` or `malloc`.
+
+
+Again, note that the count is not considered to be a part of
+ the logical state of the object, and hence the conversion from
+ `const` to non-`const` -
+ `count` is in effect a `mutable`
+ type.
+
+
+The allocator functions themselves are fairly
+ straightforward:
+```
+
+void \*operator new(size\_t size, const countable\_new &)
+{
+    count \*allocated = static\_cast<count \*>(::operator new(sizeof(count) + size));
+    \*allocated = count(); // initialise the header
+    return allocated + 1; // adjust result to point to the body
+}
+
+void operator delete(void \*ptr, const countable\_new &)
+{
+    ::operator delete(header(ptr));
+}
+
+```
+
+Given a correctly allocated header, we now need the
+ *Countable* functions to operate on `const void
+ *` to complete the picture:
+```
+
+void acquire(const void \*ptr)
+{
+    if(ptr)
+    {
+        ++header(ptr)->value;
+    }
+}
+
+void release(const void \*ptr)
+{
+    if(ptr)
+    {
+        --header(ptr)->value;
+    }
+}
+
+size\_t acquired(const void \*ptr)
+{
+    return ptr ? header(ptr)->value : 0;
+}
+
+template<typename countable\_type>
+void dispose(const countable\_type \*ptr, const void \*)
+{
+    ptr->~countable\_type();
+    operator delete(const\_cast<countable\_type \*>(ptr), countable);
+}
+
+```
+
+The most complex of these is the `dispose`
+ function that must ensure that the correct type is destructed
+ and also that the memory is collected from the correct offset.
+ It uses the value and type of first argument to perform this
+ correctly, and the second argument merely acts as a strategy
+ selector, i.e. the use of `const void *`
+ distinguishes it from the earlier dispose shown for `const
+ countability *`.
+
+
+Getting smarter
+---------------
+
+
+Now that we have a way of adding countability at creation
+ for objects of any type, what extra is needed to make this work
+ with the `countable_ptr` we defined earlier? Good
+ news: nothing!
+```
+
+class example
+{
+    ...
+};
+
+void simple()
+{
+    countable\_ptr<example> ptr(new(countable) example);
+    countable\_ptr<example> qtr(ptr);
+    ptr.clear(); // set ptr to point to null
+}   // allocated object deleted when qtr destructs
+
+```
+
+The `new(countable)` expression defines a
+ different policy for allocation and deallocation and, in common
+ with other allocators, any attempt to mix your allocation
+ policies, e.g. call `delete` on an object allocated
+ with `new(countable)`, results in undefined
+ behaviour. This is similar to what happens when you mix
+ `new[]` with `delete` or
+ `malloc` with `delete`. The whole point
+ of *Countable* conformance is that *Countable*
+ objects are used with `countable_ptr`, and this
+ ensures the correct use.
+
+
+However, accidents will happen, and inevitably you may
+ forget to allocate using `new(countable)` and
+ instead use `new`. This error and others can be
+ detected in most cases by extending the code shown here to add
+ a check member to the `count`, validating the check
+ on every access. A benefit of ensuring clear separation between
+ header and implementation source files mean that you can
+ introduce a checking version of this allocator without having
+ to recompile your code.
+
+
+Conclusion
+----------
+
+
+There are two key concepts that this article has
+ introduced:
+
+
+* The use of a generic requirements based approach to
+ simplify and adapt the use of the COUNTED BODY pattern.
+* The ability, through control of allocation, to
+ dynamically and non-intrusively add capabilities to fixed
+ types using the RUNTIME MIXIN pattern.
+
+
+The application of the two together gives rise to a new
+ variant of the essential COUNTED BODY pattern, UNINTRUSIVE
+ COUNTED BODY. You can take this theme even further and contrive
+ a simple garbage collection system for C++.
+
+
+The complete code for `countable_ptr`,
+ `countability`, and the `countable new`
+ is also available.
+*First published in* [Overload](http://www.accu.org/index.php/overloadonline)
+*25, April 1998, ISSN 1354-3172*
+
+
+
+
+
+
+
+

community/cpp.html

@@ -0,0 +1,90 @@
+---
+title: C++
+copyright: Beman Dawes 2002. Daniel James 2007. Rene Rivera 2007.
+revised: 2007-10-22 22:55:52 +0100
+---
+
+
+C++
+
+
+
+C++
+===
+
+C++ Organizations
+-----------------
+[C++
+ Standards Committee](http://www.open-std.org/jtc1/sc22/wg21/)
+Issues lists and papers give insight into current status
+ and future directions.
+[Association of C & C++
+ Users](http://www.accu.org)
+Over 2400 book reviews, and lots more.
+
+Online Publications
+-------------------
+[The
+ C++ Source](http://www.artima.com/cppsource/index.jsp)
+*"The Premier Online Journal for the C++
+ Community"*.
+
+Copies of the C++ Standard
+--------------------------
+[ANSI Store](http://webstore.ansi.org/ansidocstore/product.asp?sku=INCITS%2FISO%2FIEC+14882%2D2003)
+The full C++ Standard including TC1 corrections
+ (INCITS/ISO/IEC 14882) is available as a PDF document for $18
+ US. The document is certainly not a tutorial but is
+ interesting to those who care about the precise specification
+ of both the language and the standard library.
+[Book](http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470846747.html)
+The full C++ Standard including TC1 corrections is also
+ available in book form, list price $65 US. Since the content
+ of the book is the same as the much cheaper ANSI PDF, the
+ book form is only of interest to those who prefer a physical
+ book, say for a school or company library.
+
+Contributed Articles
+--------------------
+[C++ Committee
+ Meetings](/community/committee.html)
+FAQ for Boost Members wishing to attend a standards
+ committee meeting.
+[Generic Programming
+ Techniques](generic_programming.html)
+By [David
+ Abrahams](/users/people/dave_abrahams.html) and [Jeremy Siek](/users/people/jeremy_siek.html) describes
+ some of the techniques used in Boost libraries.
+[Error and Exception
+ Handling](error_handling.html)
+Describes approaches to errors and exceptions by [David Abrahams](/users/people/dave_abrahams.html).
+[Exception-Safety in
+ Generic Components](exception_safety.html)
+Lessons Learned from Specifying Exception-Safety for the
+ C++ Standard Library by [David Abrahams](/users/people/dave_abrahams.html).
+[Counted Body
+ Techniques](/community/counted_body.html)
+By [Kevlin
+ Henney](/users/people/kevlin_henney.html) is must reading for those interested in reference
+ counting, a widely used object management idiom. Originally
+ published in [Overload](http://www.accu.org/index.php/overloadonline)
+ magazine.
+[Implementation
+ Variations](/community/implementation_variations.html)
+Sometimes one size fits all, sometimes it doesn't. This
+ page deals with the trade-offs.
+[Feature
+ Model Diagrams in text and HTML](/community/feature_model_diagrams.html)
+Describes how to represent feature model diagrams in text
+ form.
+
+
+
+
+
+
+
+
+
+
+

community/error_handling.html

@@ -0,0 +1,267 @@
+---
+title: Error and Exception Handling
+copyright: David Abrahams 2001-2003.
+revised: 
+---
+
+
+Error and Exception Handling
+
+
+
+Error and Exception Handling
+============================
+
+References
+----------
+
+
+The following paper is a good introduction to some of the
+ issues of writing robust generic components:
+> 
+> [D. Abrahams:
+>  ``Exception Safety in Generic Components''](/community/exception_safety.html), originally
+>  published in [M. Jazayeri, R. Loos, D. Musser (eds.): Generic Programming,
+>  Proc. of a Dagstuhl Seminar, Lecture Notes on Computer
+>  Science. Volume. 1766](https://doi.org/10.1007/3-540-39953-4)
+> 
+> 
+> 
+
+
+Guidelines
+----------
+
+
+### When should I use exceptions?
+
+
+The simple answer is: ``whenever the semantic and
+ performance characteristics of exceptions are
+ appropriate.''
+
+
+An oft-cited guideline is to ask yourself the question ``is
+ this an exceptional (or unexpected) situation?'' This guideline
+ has an attractive ring to it but is usually a mistake. The
+ problem is that one person's ``exceptional'' is another's
+ ``expected'': when you look at the terms carefully, the
+ distinction evaporates and you're left with no guideline. After
+ all, if you check for an error condition, then in some sense
+ you expect it to happen, or the check is wasted code.
+
+
+A more appropriate question to ask is: ``do we want stack
+ unwinding here?'' Because actually handling an exception is
+ likely to be significantly slower than executing mainline code,
+ you should also ask: ``Can I afford stack unwinding here?'' For
+ example, a desktop application performing a long computation
+ might periodically check to see whether the user had pressed a
+ cancel button. Throwing an exception could allow the operation
+ to be canceled gracefully. On the other hand, it would
+ probably be inappropriate to throw and *handle* exceptions
+ in the inner loop of this computation because that could have a
+ significant performance impact. The guideline mentioned above
+ has a grain of truth in it: in time-critical code, throwing an
+ exception should *be* the exception, not the rule.
+
+
+### How should I design my exception classes?
+
+
+1. **Derive your exception class from
+ `std::exception`**. Except in \*very\* rare
+ circumstances where you can't afford the cost of a virtual
+ table, `std::exception` makes a reasonable
+ exception base class, and when used universally, allows
+ programmers to catch "everything" without resorting to
+ `catch(...)`. For more about
+ `catch(...)`, see below.
+2. **Use *virtual* inheritance.** This
+ insight is due to Andrew Koenig. Using virtual inheritance
+ from your exception's base class(es) prevents ambiguity
+ problems at the catch-site in case someone throws an
+ exception derived from multiple bases which have a base
+ class in common:
+ 
+```
+
+#include <iostream>
+struct my\_exc1 : std::exception { char const\* what() const throw(); };
+struct my\_exc2 : std::exception { char const\* what() const throw(); };
+struct your\_exc3 : my\_exc1, my\_exc2 {};
+
+int main()
+{
+   try { throw your\_exc3(); }
+   catch(std::exception const& e) {}
+   catch(...) { std::cout << "whoops!" << std::endl; }
+}
+
+```
+The program above prints `"whoops"` because the C++ runtime
+can't resolve which `exception` instance to match in the first
+catch clause.
+3. ***Don't* embed a std::string object** or
+ any other data member or base class whose copy constructor
+ could throw an exception. That could lead directly to
+ std::terminate() at the throw point. Similarly, it's a bad
+ idea to use a base or member whose ordinary constructor(s)
+ might throw, because, though not necessarily fatal to your
+ program, you may report a different exception than intended
+ from a *throw-expression* that includes construction
+ such as:
+ 
+```
+
+throw some\_exception();    
+
+```
+
+There are various ways to avoid copying string objects
+ when exceptions are copied, including embedding a
+ fixed-length buffer in the exception object, or managing
+ strings via reference-counting. However, consider the next
+ point before pursuing either of these approaches.
+4. **Format the `what()` message on
+ demand**, if you feel you really must format the
+ message. Formatting an exception error message is typically a
+ memory-intensive operation that could potentially throw an
+ exception. This is an operation best delayed until after
+ stack unwinding has occurred, and presumably, released some
+ resources. It's a good idea in this case to protect your
+ `what()` function with a `catch(...)`
+ block so that you have a fallback in case the formatting code
+ throws
+5. **Don't worry *too* much about the
+ `what()` message**. It's nice to have a
+ message that a programmer stands a chance of figuring out,
+ but you're very unlikely to be able to compose a relevant and
+ *user*-comprehensible error message at the point an
+ exception is thrown. Certainly, internationalization is
+ beyond the scope of the exception class author. [Peter Dimov](/users/people/peter_dimov.html) makes an
+ excellent argument that the proper use of a
+ `what()` string is to serve as a key into a table
+ of error message formatters. Now if only we could get
+ standardized `what()` strings for exceptions
+ thrown by the standard library...
+6. **Expose relevant information about the cause of
+ the error** in your exception class' public interface.
+ A fixation on the `what()` message is likely to
+ mean that you have neglected to expose information someone might
+ need, in order to make it a coherent message for users. For
+ example, if your exception reports a numeric range error,
+ it's important to have the actual numbers involved available
+ *as numbers* in the exception class' public interface
+ where error reporting code can do something intelligent with
+ them. If you only expose a textual representation of those
+ numbers in the `what()` string, you will make life
+ very difficult for programmers who need to do something more
+ (e.g. subtraction) with them than dumb output.
+7. **Make your exception class immune to
+ double-destruction** if possible. Unfortunately,
+ several popular compilers occasionally cause exception
+ objects to be destroyed twice. If you can arrange for that to
+ be harmless (e.g. by zeroing deleted pointers) your code will
+ be more robust.
+
+
+### What About Programmer Errors?
+
+
+As a developer, if I have violated a precondition of a
+ library I'm using, I don't want stack unwinding. What I want is
+ a core dump or the equivalent - a way to inspect the state of
+ the program at the exact point where the problem was detected.
+ That usually means `assert()` or something like
+ it.
+
+
+Sometimes it is necessary to have resilient APIs which can
+ stand up to nearly any kind of client abuse, but there is
+ usually a significant cost to this approach. For example, it
+ usually requires that each object used by a client be tracked
+ so that it can be checked for validity. If you need that sort
+ of protection, it can usually be provided as a layer on top of
+ a simpler API. Beware half-measures, though. An API that
+ promises resilience against some, but not all abuse is an
+ invitation to disaster. Clients will begin to rely on the
+ protection and their expectations will grow to cover
+ unprotected parts of the interface.
+
+
+**Note for Windows developers**: unfortunately,
+ the native exception-handling used by most Windows compilers
+ actually throws an exception when you use
+ `assert()`. Actually, this is true of other
+ programmer errors such as segmentation faults and
+ divide-by-zero errors. One problem with this is that if you use
+ JIT (Just In Time) debugging, there will be collateral
+ exception-unwinding before the debugger comes up because
+ `catch(...)` will catch these not-really-C++
+ exceptions. Fortunately, there is a simple but little-known
+ workaround, which is to use the following incantation:
+```
+
+extern "C" void straight\_to\_debugger(unsigned int, EXCEPTION\_POINTERS\*)
+{
+    throw;
+}
+extern "C" void (\*old\_translator)(unsigned, EXCEPTION\_POINTERS\*)
+         = \_set\_se\_translator(straight\_to\_debugger);
+
+```
+
+This technique doesn't work if the SEH is raised from within
+ a catch block (or a function called from within a catch block),
+ but it still eliminates the vast majority of JIT-masking
+ problems.
+
+
+### How should I handle exceptions?
+
+
+Often the best way to deal with exceptions is to not handle
+ them at all. If you can let them pass through your code and
+ allow destructors to handle cleanup, your code will be
+ cleaner.
+
+
+#### Avoid `catch(...)` when
+ possible
+
+Unfortunately, operating systems other than
+ Windows also wind non-C++ "exceptions" (such as thread
+ cancellation) into the C++ EH machinery, and there is sometimes
+ no workaround corresponding to the
+ `_set_se_translator` hack described above. The
+ result is that `catch(...)` can have the effect of
+ making some unexpected system notification at a point where
+ recovery is impossible to look just like a C++ exception thrown
+ from a reasonable place, invalidating the usual safe
+ assumptions that destructors and catch blocks have taken valid
+ steps to ensure program invariants during unwinding.
+
+ I reluctantly concede this point to Hillel Y. Sims, after
+ many long debates in the newsgroups: until all OSes are
+ "fixed", if every exception were derived from
+ `std::exception` and everyone substituted
+ `catch(std::exception&)` for
+ `catch(...)`, the world would be a better place.
+
+
+Sometimes, `catch(...)`, is still the most
+ appropriate pattern, in spite of bad interactions with
+ OS/platform design choices. If you have no idea what kind of
+ exception might be thrown and you really *must* stop
+ unwinding it's probably still your best bet. One obvious place
+ where this occurs is at language boundaries.
+
+
+
+
+
+
+
+
+

community/exception_safety.html

@@ -0,0 +1,764 @@
+---
+title: Exception-Safety in Generic Components
+copyright: David Abrahams 2001.
+revised: 
+---
+
+
+Exception-Safety in Generic Components
+
+
+/\*<![CDATA[\*/
+ h3.c2 {text-align: center}
+ p.c1 {font-style: italic; text-align: center}
+ /\*]]>\*/
+ 
+
+
+Exception-Safety in Generic Components
+======================================
+
+**Lessons Learned from Specifying
+ Exception-Safety for the C++ Standard Library**
+
+
+### [David Abrahams](http://daveabrahams.com)
+
+
+### [dave@boostpro.com](mailto:dave@boostpro.com)
+
+
+**Abstract.** This paper represents the
+ knowledge accumulated in response to a real-world need: that
+ the C++ Standard Template Library exhibit useful and
+ well-defined interactions with exceptions, the error-handling
+ mechanism built-in to the core C++ language. It explores the
+ meaning of exception-safety, reveals surprising myths about
+ exceptions and genericity describes valuable tools for
+ reasoning about program correctness, and outlines an automated
+ testing procedure for verifying exception-safety.
+
+
+**Keywords:** exception-safety, exceptions,
+ STL, C++
+
+
+1 What is exception-safety?
+---------------------------
+
+
+Informally, exception-safety in a component means that it
+ exhibits reasonable behavior when an exception is thrown during
+ its execution. For most people, the term
+ “reasonable” includes all the usual expectations
+ for error-handling: that resources should not be leaked, and
+ that the program should remain in a well-defined state so that
+ execution can continue. For most components, it also includes
+ the expectation that when an error is encountered, it is
+ reported to the caller.
+
+
+More formally, we can describe a component as minimally
+ exception-safe if, when exceptions are thrown from within that
+ component, its invariants are intact. Later on, we'll see that
+ at least three different levels of exception-safety can be
+ usefully distinguished. These distinctions can help us to
+ describe and reason about the behavior of large systems.
+
+
+In a generic component, we usually have an additional
+ expectation of *exception-neutrality*, which means that
+ exceptions thrown by a component's type parameters should be
+ propagated, unchanged, to the component's caller.
+
+
+2 Myths and Superstitions
+-------------------------
+
+
+Exception-safety seems straightforward so far: it doesn't
+ constitute anything more than we'd expect from code using more
+ traditional error-handling techniques. It might be worthwhile,
+ however, to examine the term from a psychological viewpoint.
+ Nobody ever spoke of “error-safety” before C++ had
+ exceptions.
+
+
+It's almost as though exceptions are viewed as a
+ *mysterious attack* on otherwise correct code, from which
+ we must protect ourselves. Needless to say, this doesn't lead
+ to a healthy relationship with error handling! During
+ standardization, a democratic process that requires broad
+ support for changes, I encountered many widely-held
+ superstitions. To even begin the discussion of
+ exception-safety in generic components, it may be worthwhile
+ confronting a few of them.
+
+
+*“Interactions between templates and exceptions are
+ not well-understood.”* This myth, often heard from
+ those who consider these both new language features, is easily
+ disposed of: there simply are no interactions. A template, once
+ instantiated, works in all respects like an ordinary class or
+ function. A simple way to reason about the behavior of a
+ template with exceptions is to think of how a specific
+ instantiation of that template works. Finally, the genericity
+ of templates should not cause special concern. Although the
+ component's client supplies part of the operation (which may,
+ unless otherwise specified, throw arbitrary exceptions), the
+ same is true of operations using familiar virtual functions or
+ simple function pointers.
+
+
+*“ It is well known to be impossible to write an
+ exception-safe generic container.”* This claim is
+ often heard concerning an article by Tom Cargill
+ [[4]](#reference4 "Tom Cargill, “Exception Handling: A False Sense of Security”, C++ Report, Nov-Dec 1994") in which he explores the
+ problem of exception-safety for a generic stack template. In
+ his article, Cargill raises many useful questions, but
+ unfortunately fails to present a solution to his
+ problem.[1](#footnote1 "Probably the greatest impediment to a solution in Cargill's case was an unfortunate combination of choices on his part: the interface he chose for his container was incompatible with his particular demands for safety. By changing either one he might have solved the problem.") He concludes by suggesting
+ that a solution may not be possible. Unfortunately, his article
+ was read by many as “proof” of that speculation.
+ Since it was published there have been many examples of
+ exception-safe generic components, among them the C++ standard
+ library containers.
+
+
+*“Dealing with exceptions will slow code down, and
+ templates are used specifically to get the best possible
+ performance.”* A good implementation of C++ will not
+ devote a single instruction cycle to dealing with exceptions
+ until one is thrown, and then it can be handled at a speed
+ comparable with that of calling a function [[7]](#reference7 "Bjarne Stroustrup, The Design And Evolution of C++. Addison Wesley, Reading, MA, 1995, ISBN 0-201-54330-3, Section 16.9.1."). That alone gives
+ programs using exceptions performance equivalent to that of a
+ program which ignores the possibility of errors. Using
+ exceptions can result in faster programs than
+ “traditional” error handling methods for other
+ reasons. First, a catch block indicates to the compiler
+ which code is devoted to error-handling; it can then be
+ separated from the usual execution path, improving locality of
+ reference. Second, code using “traditional” error
+ handling must typically test a return value for errors after
+ every single function call; using exceptions completely
+ eliminates that overhead.
+
+
+*“Exceptions make it more difficult to reason about
+ a program's behavior.”* Usually cited in support of
+ this myth is the way “hidden” execution paths are
+ followed during stack-unwinding. Hidden execution paths are
+ nothing new to any C++ programmer who expects local variables
+ to be destroyed upon returning from a function:
+```
+
+ErrorCode f( int& result )         // 1 
+{                                  // 2 
+    X x;                           // 3 
+    ErrorCode err = x.g( result ); // 4 
+    if ( err != kNoError )         // 5 
+        return err;                // 6 
+    // ...More code here... 
+    return kNoError;               // 7 
+}
+
+```
+
+In the example above, there is a “hidden” call
+ to `X::~X()` in lines 6 and 7. Granted, using
+ exceptions, there is no code devoted to error handling
+ visible:
+```
+
+int f()                 // 1 
+{                       // 2 
+    X x;                // 3 
+    int result = x.g(); // 4 
+    // ...More code here... 
+    return result;      // 5 
+} 
+
+```
+
+For many programmers more familiar with exceptions, the
+ second example is actually more readable and understandable
+ than the first. The “hidden” code paths include the
+ same calls to destructors of local variables. Also, they
+ follow a simple pattern which acts *exactly* as though
+ there was a potential return statement after each function
+ call in case of an exception. Readability is enhanced because
+ the normal path of execution is unobscured by error-handling,
+ and return values are freed up to be used naturally.
+
+
+There is an even more important way in which exceptions can
+ enhance correctness: by allowing simple class invariants. In
+ the first example, if `x`'s constructor should need
+ to allocate resources, it has no way to report a failure: in
+ C++, constructors have no return values. The usual result when
+ exceptions are avoided is that classes requiring resources must
+ include a separate initializer function which finishes the job
+ of construction. The programmer can therefore never be sure,
+ when an object of class `X` is used, whether he is
+ handling a full-fledged `X` or some abortive attempt
+ to construct one (or worse: someone simply forgot to call the
+ initializer!)
+
+
+3 A contractual basis for exception-safety
+------------------------------------------
+
+
+A non-generic component can be described as exception-safe
+ in isolation, but because of its configurability by client
+ code, exception-safety in a generic component usually depends
+ on a contract between the component and its clients. For
+ example, the designer of a generic component might require that
+ an operation that is used in the component's destructor not
+ throw any exceptions.[2](#footnote2 " It is usually inadvisable to throw an exception from a destructor in C++, since the destructor may itself be called during the stack-unwinding caused by another exception. If the second exception is allowed to propagate beyond the destructor, the program is immediately terminated.") The generic component might,
+ in return, provide one of the following guarantees:
+
+
+* The *basic* guarantee: that the invariants of the
+ component are preserved, and no resources are leaked.
+* The *strong* guarantee: that the operation has
+ either completed successfully or thrown an exception, leaving
+ the program state exactly as it was before the operation
+ started.
+* The *no-throw* guarantee: that the operation will
+ not throw an exception.
+
+
+The basic guarantee is a simple minimum standard for
+ exception-safety to which we can hold all components. It says
+ simply that after an exception, the component can still be used
+ as before. Importantly, the preservation of invariants allows
+ the component to be destroyed, potentially as part of
+ stack-unwinding. This guarantee is actually less useful than it
+ might at first appear. If a component has many valid states,
+ after an exception we have no idea what state the component is
+ in; only that the state is valid. The options for recovery, in
+ this case, are limited: either destruction or resetting the
+ component to some known state before further use. Consider the
+ following example:
+```
+
+template <class X> 
+void print\_random\_sequence() 
+{ 
+    std::vector<X> v(10); // A vector of 10 items 
+    try { 
+        // Provides only the *basic* guarantee 
+        v.insert( v.begin(), X() ); 
+    } 
+    catch(...) {} // ignore any exceptions above 
+    // print the vector's contents 
+    std::cout "(" << v.size() << ") "; 
+    std::copy( v.begin(), v.end(), 
+    std::ostream\_iterator<X>( std::cout, " " ) ); 
+} 
+
+```
+
+Since all we know about v after an exception is that it is
+ valid, the function is allowed to print any random sequence of
+ `X`s.[3](#footnote3 "In practice, of course, this function would make an extremely poor random sequence generator!") It is “safe” in
+ the sense that it is not allowed to crash, but its output may
+ be unpredictable.
+
+
+The *strong* guarantee provides full
+ “commit-or-rollback” semantics. In the case of C++
+ standard containers, this means, for example, that if an
+ exception is thrown all iterators remain valid. We also know
+ that the container has the same elements as before the
+ exception was thrown. A transaction that has no effects if it
+ fails has obvious benefits: the program state is simple and
+ predictable in case of an exception. In the C++ standard
+ library, nearly all of the operations on the node-based
+ containers list, set, multiset, map, and multimap provide the
+ *strong* guarantee.[4](#footnote4 "It is worth noting that mutating algorithms usually cannot provide the strong guarantee: to roll back a modified element of a range, it must be set back to its previous value using operator=, which itself might throw. In the C++ standard library, there are a few exceptions to this rule, whose rollback behavior consists only of destruction: uninitialized_copy, uninitialized_fill, and uninitialized_fill_n.")).
+
+
+The *no-throw* guarantee is the strongest of all, and
+ it says that an operation is guaranteed not to throw an
+ exception: it always completes successfully. This guarantee is
+ necessary for most destructors, and indeed the destructors of
+ C++ standard library components are all guaranteed not to throw
+ exceptions. The *no-throw* guarantee turns out to be
+ important for other reasons, as we shall see.[5](#footnote5 "All type parameters supplied by clients of the C++ standard library are required not to throw from their destructors. In return, all components of the C++ standard library provide at least the basic guarantee.")
+
+
+4 Legal Wrangling
+-----------------
+
+
+Inevitably, the contract can get more complicated: a quid
+ pro quo arrangement is possible. Some components in the C++
+ Standard Library give one guarantee for arbitrary type
+ parameters, but give a stronger guarantee in exchange for
+ additional promises from the client type that no exceptions
+ will be thrown. For example, the standard container operation
+ `vector<T>::erase` gives the *basic*
+ guarantee for any `T`, but for types whose copy
+ constructor and copy assignment operator does not throw, it gives
+ the *no-throw* guarantee.[6](#footnote6 "Similar arrangements might have been made in the C++ standard for many of the mutating algorithms, but were never considered due to time constraints on the standardization process.")
+
+
+5 What level of exception-safety should a component
+ specify?
+-------------------------------------------------------------
+
+
+From a client's point-of-view, the strongest possible level
+ of safety would be ideal. Of course, the *no-throw*
+ guarantee is simply impossible for many operations, but what
+ about the *strong* guarantee? For example, suppose we
+ wanted atomic behavior for
+ `vector<T>::insert`. Insertion into the middle
+ of a vector requires copying elements after the insertion point
+ into later positions, to make room for the new element. If
+ copying an element can fail, rolling back the operation would
+ require “undoing” the previous copies...which
+ depends on copying again. If copying back should fail (as it
+ likely would), we have failed to meet our guarantee.
+
+
+One possible alternative would be to redefine
+ `insert` to build the new array contents in a fresh
+ piece of memory each time, and only destroy the old contents
+ when that has succeeded. Unfortunately, there is a non-trivial
+ cost if this approach is followed: insertions near the end of a
+ vector which might have previously caused only a few copies
+ would now cause every element to be copied. The *basic*
+ guarantee is a “natural” level of safety for this
+ operation, which it can provide without violating its
+ performance guarantees. In fact all of the operations in the
+ library appears to have such a “natural” level of
+ safety.
+
+
+Because performance requirements were already a
+ well-established part of the draft standard and because
+ performance is a primary goal of the STL, there was no attempt
+ to specify more safety than could be provided within those
+ requirements. Although not all of the library gives the
+ *strong* guarantee, almost any operation on a standard
+ container which gives the *basic* guarantee can be made
+ *strong* using the “make a new copy” strategy
+ described above:
+```
+
+template <class Container, class BasicOp> 
+void MakeOperationStrong( Container& c, const BasicOp& op ) 
+{ 
+    Container tmp(c); // Copy c 
+    op(tmp); // Work on the copy 
+    c.swap(tmp); // Cannot fail[7](#footnote7 "Associative containers whose Compare object might throw an exception when copied cannot use this technique, since the swap function might fail.")
+}
+
+```
+
+This technique can be folded into a wrapper class to make a
+ similar container which provides stronger guarantees (and
+ different performance characteristics).[8](#footnote8 "This suggests another potential use for the oft-wished-for but as yet unseen container traits<> template: automated container selection to meet exceptionsafety constraints.")
+
+
+6 Should we take everything we can get?
+---------------------------------------
+
+
+By considering a particular implementation, we can hope to
+ discern a natural level of safety. The danger in using this to
+ establish requirements for a component is that the
+ implementation might be restricted. If someone should come up
+ with a more-efficient implementation which we'd like to use, we
+ may find that it's incompatible with our exception-safety
+ requirements. One might expect this to be of no concern in the
+ well-explored domains of data structures and algorithms covered
+ by the STL, but even there, advances are being made. A good
+ example is the recent *introsort* algorithm [[6]](#reference6 "D. R. Musser, “ Introspective Sorting and Selection Algorithms” Software-Practice and Experience 27(8):983-993, 1997."), which represents a
+ substantial improvement in worst-case complexity over the
+ well-established *quicksort*.
+
+
+To determine exactly how much to demand of the standard
+ components, I looked at a typical real-world scenario. The
+ chosen test case was a “ composite container.” Such
+ a container, built of two or more standard container
+ components, is not only commonly needed, but serves as a simple
+ representative case for maintaining invariants in larger
+ systems:
+```
+
+// SearchableStack - A stack which can be efficiently searched 
+// for any value. 
+template <class T> 
+class SearchableStack 
+{ 
+ public: 
+    void push(const T& t); // O(log n) 
+    void pop(); // O(log n) 
+    bool contains(const T& t) const; // O(log n) 
+    const T& top() const; // O(1) 
+ private: 
+    std::set<T> set\_impl; 
+    std::list<std::set<T>::iterator> list\_impl; 
+}; 
+
+```
+
+The idea is that the list acts as a stack of set iterators:
+ every element goes into the set first, and the resulting
+ position is pushed onto the list. The invariant is
+ straightforward: the set and the list should always have the
+ same number of elements, and every element of the set should be
+ referenced by an element of the list. The following
+ implementation of the push function is designed to give the
+ *strong* guarantee within the natural levels of safety
+ provided by set and list:
+```
+
+template <class T>                                // 1 
+void SearchableStack<T>::push(const T& t)         // 2 
+{                                                       // 3 
+    set<T>::iterator i = set\_impl.insert(t);      // 4 
+    try                                                 // 5 
+    {                                                   // 6 
+        list\_impl.push\_back(i);                         // 7 
+    }                                                   // 8 
+    catch(...)                                          // 9 
+    {                                                   // 10 
+        set\_impl.erase(i);                              // 11 
+        throw;                                          // 12 
+    }                                                   // 13 
+}                                                       // 14 
+
+```
+
+What does our code require of the library? We need
+ to examine the lines where non-const operations occur:
+
+
+* Line 4: if the insertion fails but `set_impl`
+ is modified in the process, our invariant is violated. We
+ need to be able to rely on the *strong* guarantee from
+ `set<T>::insert`.
+* Line 7: likewise, if `push_back` fails, but
+ `list_impl` is modified in the process, our
+ invariant is violated, so we need to be able to rely on the
+ *strong* guarantee from list<T>::insert.
+* Line 11: here we are “rolling back” the
+ insertion on line 4. If this operation should fail, we will
+ be unable to restore our invariant. We absolutely depend on
+ the *no-throw* guarantee from
+ `set<T>::erase`.[9](#footnote9 "One might be tempted to surround the erase operation with a try/catch block to reduce the requirements on set< T> and the problems that arise in case of an exception, but in the end that just begs the question. First, erase just failed and in this case there are no viable alternative ways to produce the necessary result. Second and more generally, because of the variability of its type parameters a generic component can seldom be assured that any alternatives will succeed.")
+* Line 11: for the same reasons, we also depend on being
+ able to pass the `i` to the `erase`
+ function: we need the *no-throw* guarantee from the copy
+ constructor of `set<T>::iterator`.
+
+
+I learned a great deal by approaching the question this way
+ during standardization. First, the guarantee specified for the
+ composite container depends on stronger guarantees
+ from its components (the *no-throw* guarantees in line
+ 11). Also, I took advantage of all of the natural levels of
+ safety to implement this simple example. Finally, the analysis
+ revealed a requirement on iterators which I had previously
+ overlooked when operations were considered on their own. The
+ conclusion was that we should provide as much of the natural
+ level of safety as possible. Faster but less-safe
+ implementations could always be provided as extensions to the
+ standard components. [10](#footnote10 "The prevalent philosophy in the design of STL was that functionality that wasn't essential to all uses should be left out in favor of efficiency, as long as that functionality could be obtained when needed by adapting the base components. This departs from that philosophy, but it would be difficult or impossible to obtain even the basic guarantee by adapting a base component that doesn't already have it.")
+
+
+7 Automated testing for exception-safety
+----------------------------------------
+
+
+As part of the standardization process, I produced an
+ exception-safe reference implementation of the STL.
+ Error-handling code is seldom rigorously tested in real life,
+ in part because it is difficult to cause error conditions to
+ occur. It is very common to see error-handling code that
+ crashes the first time it is executed ...in a shipping product!
+ To bolster confidence that the implementation worked
+ as advertised, I designed an automated test suite, based on an
+ exhaustive technique due to my colleague Matt Arnold.
+
+
+The test program started with the basics: reinforcement and
+ instrumentation, especially of the global operators
+ `new` and `delete`.[11](#footnote11 "An excellent discussion on how to fortify memory subsystems can be found in: Steve Maguire, Writing Solid Code, Microsoft Press, Redmond, WA, 1993, ISBN 1-55615- 551-4.")Instances of the components
+ (containers and algorithms) were created, with type parameters
+ chosen to reveal as many potential problems as possible. For
+ example, all type parameters were given a pointer to
+ heap-allocated memory, so that leaking a contained object would
+ be detected as a memory leak.
+
+
+Finally, a scheme was designed that could cause an operation
+ to throw an exception at each possible point of failure. At the
+ beginning of every client-supplied operation which is allowed
+ to throw an exception, a call to `ThisCanThrow` was
+ added. A call to `ThisCanThrow` also had to be added
+ everywhere that the generic operation being tested might throw
+ an exception, for example in the global operator
+ `new`, for which an instrumented replacement was
+ supplied.
+```
+
+// Use this as a type parameter, e.g. vector<TestClass> 
+struct TestClass 
+{ 
+    TestClass( int v = 0 ) 
+        : p( ThisCanThrow(), new int( v ) ) {} 
+    TestClass( const TestClass& rhs ) 
+        : p( ThisCanThrow(), new int( \*rhs.p ) ) {} 
+    const TestClass& operator=( const TestClass& rhs ) 
+        { ThisCanThrow(); \*p = \*rhs.p; } 
+    bool operator==( const TestClass& rhs ) const
+        { ThisCanThrow(); return \*p == \*rhs.p; } 
+    ...etc... 
+    ~TestClass() { delete p; } 
+};
+
+```
+
+`ThisCanThrow` simply decrements a “throw
+ counter” and, if it has reached zero, throws an
+ exception. Each test takes a form which begins the counter at
+ successively higher values in an outer loop and repeatedly
+ attempts to complete the operation being tested. The result is
+ that the operation throws an exception at each successive step
+ along its execution path that can possibly fail. For example,
+ here is a simplified version of the function used to test the
+ *strong* guarantee: [12](#footnote12 "Note that this technique requires that the operation being tested be exception-neutral. If the operation ever tries to recover from an exception and proceed, the throw counter will be negative, and subsequent operations that might fail will not be tested for exception-safety.")
+```
+
+extern int gThrowCounter; // The throw counter
+void ThisCanThrow() 
+{ 
+    if (gThrowCounter-- == 0) 
+        throw 0; 
+} 
+ 
+template <class Value, class Operation> 
+void StrongCheck(const Value& v, const Operation& op) 
+{ 
+    bool succeeded = false; 
+    for (long nextThrowCount = 0; !succeeded; ++nextThrowCount) 
+    { 
+        Value duplicate = v; 
+        try 
+        { 
+            gThrowCounter = nextThrowCount; 
+            op( duplicate ); // Try the operation 
+            succeeded = true; 
+        } 
+        catch(...) // Catch all exceptions 
+        { 
+            bool unchanged = duplicate == v; // Test *strong* guarantee 
+            assert( unchanged ); 
+        } 
+        // Specialize as desired for each container type, to check 
+        // integrity. For example, size() == distance(begin(),end()) 
+        CheckInvariant(v); // Check any invariant 
+    } 
+}
+
+```
+
+Notably, this kind of testing is much easier and less
+ intrusive with a generic component than with non-generics,
+ because testing-specific type parameters can be used without
+ modifying the source code of the component being tested. Also,
+ generic functions like `StrongCheck` above were
+ instrumental in performing the tests on a wide range of values
+ and operations.
+
+
+8 Further Reading
+-----------------
+
+
+To my knowledge, there are currently only two descriptions
+ of STL exception-safety available. The original specification
+ [[2]](#reference2 "D. Abrahams, Exception Safety in STLport") for the reference
+ exception-safe implementation of the STL is an informal
+ specification, simple and self-explanatory (also verbose), and
+ uses the *basic-* and *strong-*guarantee distinctions
+ outlined in this article. It explicitly forbids leaks, and
+ differs substantively from the final C++ standard in the
+ guarantees it makes, though they are largely identical. I hope
+ to produce an updated version of this document soon.
+
+
+The description of exception-safety in the C++ Standard
+ [[1]](#reference1 "International Standard ISO/IEC 14882, Information Technology-Programming Languages-C++, Document Number ISO/IEC 14882-1998") is only slightly more
+ formal, but relies on hard-to-read “standardese”
+ and an occasionally subtle web of implication.[13](#footnote13 "The changes to the draft standard which introduced exception-safety were made late in the process, when amendments were likely to be rejected solely based on the number of altered words. Unfortunately, the result compromises clarity somewhat in favor of brevity. Greg Colvin was responsible for the clever language-lawyering needed to minimize the extent of these changes.") In particular, leaks are
+ not treated directly at all. It does have the advantage that it
+ *is* the standard.
+
+
+The original reference implementation [[5]](#reference5 "B. Fomitchev, Adapted SGI STL Version 1.0, with exception handling code by D. Abrahams") of the exception-safe STL
+ is an adaptation of an old version of the SGI STL, designed for
+ C++ compilers with limited features. Although it is not a
+ complete STL implementation, the code may be easier to read,
+ and it illustrates a useful base-class technique for
+ eliminating exception-handling code in constructors. The full
+ test suite [[3]](#reference3 "D. Abrahams and B. Fomitchev, Exception Handling Test Suite") used to validate the
+ reference implementation has been used successfully to validate
+ all recent versions of the SGI STL, and has been adapted to
+ test one other vendor's implementation (which failed). As noted
+ on the documentation page, it also seems to have the power to
+ reveal hidden compiler bugs, particularly where optimizers
+ interact with exception-handling code.
+
+
+References
+----------
+
+
+1. International
+ Standard ISO/IEC 14882, *Information Technology-Programming
+ Languages-C++*, Document Number ISO/IEC 14882-1998,
+ available from <http://webstore.ansi.org/ansidocstore/default.asp>.
+2. D. Abrahams,
+ *Exception Safety in STLport*, available at <http://www.stlport.org/doc/exception_safety.html>.
+3. D. Abrahams and
+ B. Fomitchev, *Exception Handling Test Suite*, available
+ at <http://www.stlport.org/doc/eh_testsuite.html>.
+4. Tom Cargill,
+ “Exception Handling: A False Sense of Security,”
+ C++ Report, Nov-Dec 1994, also available at [http://www.awprofessional.com/content/images/020163371x/supplements/Exception\_Handling\_Article.html](http://www.informit.com/content/images/020163371x/supplements/Exception_Handling_Article.html).
+5. B. Fomitchev,
+ *Adapted SGI STL Version 1.0*, with exception handling
+ code by D. Abrahams, available at <http://www.stlport.org>.
+6. D. R. Musser,
+ “Introspective Sorting and Selection Algorithms,”
+ *Software-Practice and Experience* 27(8):983-993,
+ 1997.
+7. Bjarne
+ Stroustrup, *The Design And Evolution of C++*. Addison
+ Wesley, Reading, MA, 1995, ISBN 0-201-54330-3, Section
+ 16.9.1.
+
+
+Footnotes
+---------
+
+
+1 Probably the
+ greatest impediment to a solution in Cargill's case was an
+ unfortunate combination of choices on his part: the interface
+ he chose for his container was incompatible with his particular
+ demands for safety. By changing either one he might have solved
+ the problem.
+
+
+2 It is usually
+ inadvisable to throw an exception from a destructor in C++,
+ since the destructor may itself be called during the
+ stack-unwinding caused by another exception. If the second
+ exception is allowed to propagate beyond the destructor, the
+ program is immediately terminated.
+
+
+3 In practice of
+ course, this function would make an extremely poor random
+ sequence generator!
+
+
+4 It is worth noting
+ that mutating algorithms usually cannot provide the
+ *strong* guarantee: to roll back a modified element of a
+ range, it must be set back to its previous value using
+ `operator=`, which itself might throw. In the C++
+ standard library, there are a few exceptions to this rule,
+ whose rollback behavior consists only of destruction:
+ `uninitialized_copy`,
+ `uninitialized_fill`, and
+ `uninitialized_fill_n`.
+
+
+5 All type parameters
+ supplied by clients of the C++ standard library are required
+ not to throw from their destructors. In return, all components
+ of the C++ standard library provide at least the *basic*
+ guarantee.
+
+
+6 Similar
+ arrangements might have been made in the C++ standard for many
+ of the mutating algorithms, but were never considered due to
+ time constraints on the standardization process.
+
+
+7 Associative
+ containers whose `Compare` object might throw an
+ exception when copied cannot use this technique, since the swap
+ function might fail.
+
+
+8 This suggests
+ another potential use for the oft-wished-for but as yet unseen
+ `container_traits<>` template: automated
+ container selection to meet exception-safety constraints.
+
+
+9 One might be
+ tempted to surround the erase operation with a
+ `try`/`catch` block to reduce the
+ requirements on `set<T>` and the problems that
+ arise in case of an exception, but in the end that just begs
+ the question. First, erase just failed and in this case there
+ are no viable alternative ways to produce the necessary result.
+ Second and more generally, because of the variability of its
+ type parameters a generic component can seldom be assured that
+ any alternatives will succeed.
+
+
+10 The prevalent
+ philosophy in the design of STL was that functionality that
+ wasn't essential to all uses should be left out in favor of
+ efficiency, as long as that functionality could be obtained
+ when needed by adapting the base components. This departs from
+ that philosophy, but it would be difficult or impossible to
+ obtain even the *basic* guarantee by adapting a base
+ component that doesn't already have it.
+
+
+11 An excellent
+ discussion on how to fortify memory subsystems can be found in:
+ Steve Maguire, Writing Solid Code, Microsoft Press, Redmond,
+ WA, 1993, ISBN 1-55615- 551-4.
+
+
+12 Note that this
+ technique requires that the operation being tested be
+ exception-neutral. If the operation ever tries to recover from
+ an exception and proceed, the throw counter will be negative,
+ and subsequent operations that might fail will not be tested
+ for exception-safety.
+
+
+13 The changes to
+ the draft standard which introduced exception-safety were made
+ late in the process, when amendments were likely to be rejected
+ solely based on the number of altered words.
+ Unfortunately, the result compromises clarity somewhat in favor
+ of brevity. Greg Colvin was responsible for the clever
+ language-lawyering needed to minimize the extent of these
+ changes.
+
+
+
+
+
+
+
+
+

community/feature_model_diagrams.html

@@ -0,0 +1,169 @@
+---
+title: Feature Model Diagrams in text and HTML
+copyright: Beman Dawes 2000.
+revised: 
+---
+
+
+Feature Model Diagrams in text and HTML
+
+
+
+Feature Model Diagrams in text and HTML
+=======================================
+
+
+By [Beman
+ Dawes](/users/people/beman_dawes.html)
+
+Introduction
+------------
+
+
+In their seminal book, Generative Programming, Czarnecki and
+ Eisenecker ([C&E](#GenerativeProgramming)))
+ describe how to build feature models [C&E 4.4] consisting
+ of a feature diagram plus semantic, rationale, and other
+ attributes. Feature models are then used to drive design cycles
+ which eventually lead to manual or automatic assembly of
+ configurations.
+
+
+Feature models provide a language to describe the library
+ variability that is often such an issue in boost.org
+ discussions. The Whorf hypothesis that "Language shapes the way
+ we think, and determines what we can think about" seems to
+ apply. In discussion of library variability issues, we have
+ been crippled by lack of a good language. With feature models,
+ we now have a language to carry on the dialog.
+
+
+The graphical feature diagrams presented by C&E are not
+ in a suitable form for the email discussions boost.org depends
+ upon. The hierarchical nature of feature diagrams can be
+ represented by a simple text-based feature diagram language. A
+ feature model can also take advantage of the hyperlinks
+ inherent in HTML.
+
+
+Grammar
+-------
+
+
+The grammar for the feature diagram language is expressed in
+ Extended Bakus-Naur Form;::= represents productions, [...]
+ represents options, {...} represents zero or more instances,
+ and represents | alternatives.
+```
+
+feature-model       ::= concept-name details { feature }
+
+feature             ::= feature-name [details]
+
+details             ::= "(" feature-list ")"      // required features
+                      | "[" feature-list "]"      // optional features
+
+feature-list        ::= element { "|" element }   // one only
+                      | element { "+" element }   // one or more
+                      | element { "," element }   // all
+                                                  // [a+b] equivalent to [a,b]
+
+element             ::= feature
+                      | details
+concept-name        ::= name
+
+feature-name        ::= name
+
+```
+
+The usual lexical conventions apply. Names are
+ case-insensitive and consist of a leading letter, followed by
+ letters, digits, underscores or hyphens, with no spaces
+ allowed.
+
+
+At least one instance of each name should be hyperlinked to
+ the corresponding [Feature
+ Description](#FeatureDescriptions).
+
+
+While the grammar is intended for written communication
+ between people, it may also be trivially machine parsed for use
+ by automatic tools.
+Descriptive information is associated with each concept or
+ feature. According to [C&E 4.4.2] this includes:
+
+
+* Semantic descriptions.
+* Rationale.
+* Stakeholders and client programs.
+* Exemplar systems.
+* Constraints and default dependency rules.
+* Availability sites, binding sites, and binding mode.
+* Open/Closed attribute.
+
+
+What is a Feature?
+------------------
+
+
+A feature [C&E 4.9.1] is "anything users or client
+ programs might want to control about a concept. Thus, during
+ feature modeling, we document no only functional features ...
+ but also implementation features, ..., various optimizations,
+ alternative implementation techniques, and so on."
+
+
+Example
+-------
+```
+
+special-container ( organization,
+                    performance,
+                    interface  )         // all required
+
+organization [ ordered + indexed ]       // zero or more (4 configurations)
+
+indexed [ hash-function ]                // zero or one  (2 configurations)
+
+performance ( fast | small | balanced )  // exactly one  (3 configurations)
+
+interface ( STL-style + cursor-style )   // one or more  (3 configurations)
+
+```
+
+There should be feature descriptions for
+ `some-container, organization, ordered, indexed,
+ hash-function, performance, fast, small, balanced, interface,
+ STL-style, and cursor-style`.
+
+
+The number of possible configurations is (2 + 2\*2) \* 3 \* 3 =
+ 54, assuming no constraints.
+
+
+There are equivalent representations. For example:
+```
+
+special-container ( organization[ ordered+indexed[ hash-function ]],
+                    performance( fast|small|balanced ),
+                    interface( STL-style+cursor-style ) )
+
+```
+
+References
+----------
+
+
+Krzysztof Czarnecki and Ulrich W.
+ Eisenecker, [Generative
+ Programming](http://www.generative-programming.org), Addison-Wesley, 2000, ISBN 0-201-30977-7
+
+
+
+
+
+
+
+
+

community/generic_programming.html

@@ -0,0 +1,469 @@
+---
+title: Generic Programming Techniques
+copyright: David Abrahams 2001.
+revised: 
+---
+
+
+Generic Programming Techniques
+
+
+/\*<![CDATA[\*/
+ a.c2 {font-style: italic}
+ strong.c1 {font-style: italic}
+ /\*]]>\*/
+ 
+
+
+Generic Programming Techniques
+==============================
+
+This is an incomplete survey of some of the generic
+ programming techniques used in the [boost](/)
+ libraries.
+
+
+Table of Contents
+-----------------
+
+
+* [Introduction](#introduction)
+* [The Anatomy of a Concept](#concept)
+* [Traits](#traits)
+* [Tag Dispatching](#tag_dispatching)
+* [Adaptors](#adaptors)
+* [Type Generators](#type_generator)
+* [Object Generators](#object_generator)
+* [Policy Classes](#policy)
+
+
+Introduction
+------------
+
+
+Generic programming is about generalizing software
+ components so that they can be easily reused in a wide variety
+ of situations. In C++, class and function templates are
+ particularly effective mechanisms for generic programming
+ because they make the generalization possible without
+ sacrificing efficiency.
+
+
+As a simple example of generic programming, we will look at
+ how one might generalize the `memcpy()` function of
+ the C standard library. An implementation of
+ `memcpy()` might look like the following:
+```
+
+void\* memcpy(void\* region1, const void\* region2, size\_t n)
+{
+  const char\* first = (const char\*)region2;
+  const char\* last = ((const char\*)region2) + n;
+  char\* result = (char\*)region1;
+  while (first != last)
+    \*result++ = \*first++;
+  return result;
+}
+
+```
+
+The `memcpy()` function is already generalized to
+ some extent by the use of `void*` so that the
+ function can be used to copy arrays of different kinds of data.
+ But what if the data we would like to copy is not in an array?
+ Perhaps it is in a linked list. Can we generalize the notion of
+ copy to any sequence of elements? Looking at the body of
+ `memcpy()`, the function's **minimal requirements** are that it needs to
+ *traverse* through the sequence using some sort of
+ pointer, *access* elements pointed to, *write* the
+ elements to the destination, and *compare* pointers to
+ know when to stop. The C++ standard library groups requirements
+ such as these into **concepts**, in
+ this case the [Input
+ Iterator](http://en.cppreference.com/w/cpp/concept/InputIterator) concept (for `region2`) and the [Output
+ Iterator](http://en.cppreference.com/w/cpp/concept/OutputIterator) concept (for `region1`).
+
+
+If we rewrite the `memcpy()` as a function
+ template, and use the [Input
+ Iterator](http://en.cppreference.com/w/cpp/concept/InputIterator) and [Output
+ Iterator](http://en.cppreference.com/w/cpp/concept/OutputIterator) concepts to describe the requirements on the
+ template parameters, we can implement a highly reusable
+ `copy()` function in the following way:
+```
+
+template <typename InputIterator, typename OutputIterator>
+OutputIterator
+copy(InputIterator first, InputIterator last, OutputIterator result)
+{
+  while (first != last)
+    \*result++ = \*first++;
+  return result;
+}
+
+```
+
+Using the generic `copy()` function, we can now
+ copy elements from any kind of sequence, including a linked
+ list that exports iterators such as `std::[list](http://en.cppreference.com/w/cpp/container/list)`.
+```
+
+#include <list>
+#include <vector>
+#include <iostream>
+
+int main()
+{
+  const int N = 3;
+  std::vector<int> region1(N);
+  std::list<int> region2;
+
+  region2.push\_back(1);
+  region2.push\_back(0);
+  region2.push\_back(3);
+  
+  std::copy(region2.begin(), region2.end(), region1.begin());
+
+  for (int i = 0; i < N; ++i)
+    std::cout << region1[i] << " ";
+  std::cout << std::endl;
+}
+
+```
+
+Anatomy of a
+ Concept
+---------------------
+
+
+A **concept** is a set of
+ requirements consisting of valid expressions, associated types,
+ invariants, and complexity guarantees. A type that satisfies
+ the requirements is said to **model**
+ the concept. A concept can extend the requirements of another
+ concept, which is called **refinement**.
+
+
+* **Valid Expressions** are
+ C++ expressions which must compile successfully for the
+ objects involved in the expression to be considered
+ *models* of the concept.
+* **Associated Types** are
+ types that are related to the modeling type in that they
+ participate in one or more of the valid expressions.
+ Typically associated types can be accessed either through
+ typedefs nested within a class definition for the modeling
+ type, or they are accessed through a [traits
+ class](#traits).
+* **Invariants** are run-time characteristics
+ of the objects that must always be true, that is, the
+ functions involving the objects must preserve these
+ characteristics. The invariants often take the form of
+ pre-conditions and post-conditions.
+* **Complexity Guarantees** are maximum limits
+ on how long the execution of one of the valid expressions
+ will take, or how much of various resources its computation
+ will use.
+
+
+The concepts used in the C++ Standard Library are documented
+ at the [C++ reference
+ website](http://en.cppreference.com/w/).
+
+
+Traits
+------
+
+
+A traits class provides a way of associating information
+ with a compile-time entity (a type, integral constant, or
+ address). For example, the class template [`std::iterator_traits<T>`](http://en.cppreference.com/w/cpp/iterator/iterator_traits)
+ looks something like this:
+```
+
+template <class Iterator>
+struct iterator\_traits {
+  typedef ... iterator\_category;
+  typedef ... value\_type;
+  typedef ... difference\_type;
+  typedef ... pointer;
+  typedef ... reference;
+};
+
+```
+
+The traits' `value_type` gives generic code the
+ type which the iterator is "pointing at", while the
+ `iterator_category` can be used to select more
+ efficient algorithms depending on the iterator's
+ capabilities.
+
+
+A key feature of traits templates is that they're
+ *non-intrusive*: they allow us to associate information
+ with arbitrary types, including built-in types and types
+ defined in third-party libraries, Normally, traits are
+ specified for a particular type by (partially) specializing the
+ traits template.
+
+
+For an in-depth description of
+ `std::iterator_traits`, see [this
+ page](http://en.cppreference.com/w/cpp/iterator/iterator_traits). Another very different expression of the traits idiom
+ in the standard is `std::numeric_limits<T>`
+ which provides constants describing the range and capabilities
+ of numeric types.
+
+
+Tag
+ Dispatching
+----------------
+
+
+Tag dispatching is a way of using function overloading to
+ dispatch based on properties of a type, and is often used hand
+ in hand with traits classes. A good example of this synergy is
+ the implementation of the [`std::advance()`](http://en.cppreference.com/w/cpp/iterator/advance) function in the C++ Standard
+ Library, which increments an iterator `n` times.
+ Depending on the kind of iterator, there are different
+ optimizations that can be applied in the implementation. If the
+ iterator is [random
+ access](http://en.cppreference.com/w/cpp/concept/RandomAccessIterator) (can jump forward and backward arbitrary distances),
+ then the `advance()` function can simply be
+ implemented with `i += n`, and is very efficient:
+ constant time. Other iterators must be `advance`d in
+ steps, making the operation linear in n. If the iterator is
+ [bidirectional](http://en.cppreference.com/w/cpp/concept/BidirectionalIterator), then it makes sense for `n` to be
+ negative, so we must decide whether to increment or decrement
+ the iterator.
+
+
+The relation between tag dispatching and traits classes is
+ that the property used for dispatching (in this case the
+ `iterator_category`) is often accessed through a
+ traits class. The main `advance()` function uses the
+ [`iterator_traits`](http://en.cppreference.com/w/cpp/iterator/iterator_traits) class to get the
+ `iterator_category`. It then makes a call the the
+ overloaded `advance_dispatch()` function. The
+ appropriate `advance_dispatch()` is selected by the
+ compiler based on whatever type the `iterator_category`  resolves to, either [`input_iterator_tag`](http://en.cppreference.com/w/cpp/iterator/iterator_tags), [`bidirectional_iterator_tag`](http://en.cppreference.com/w/cpp/iterator/iterator_tags), or [`random_access_iterator_tag`](http://en.cppreference.com/w/cpp/iterator/iterator_tags). A **tag** is simply a class whose only purpose is to
+ convey some property for use in tag dispatching and similar
+ techniques. Refer to [this
+ page](http://en.cppreference.com/w/cpp/iterator/iterator_tags) for a more detailed description of iterator tags.
+```
+
+namespace std {
+  struct input\_iterator\_tag { };
+  struct bidirectional\_iterator\_tag { };
+  struct random\_access\_iterator\_tag { };
+
+  namespace detail {
+    template <class InputIterator, class Distance>
+    void advance\_dispatch(InputIterator& i, Distance n, **input\_iterator\_tag**) {
+      while (n--) ++i;
+    }
+
+    template <class BidirectionalIterator, class Distance>
+    void advance\_dispatch(BidirectionalIterator& i, Distance n, 
+       **bidirectional\_iterator\_tag**) {
+      if (n >= 0)
+        while (n--) ++i;
+      else
+        while (n++) --i;
+    }
+
+    template <class RandomAccessIterator, class Distance>
+    void advance\_dispatch(RandomAccessIterator& i, Distance n, 
+       **random\_access\_iterator\_tag**) {
+      i += n;
+    }
+  }
+
+  template <class InputIterator, class Distance>
+  void advance(InputIterator& i, Distance n) {
+    typename **iterator\_traits<InputIterator>::iterator\_category** category;
+    detail::advance\_dispatch(i, n, **category**);
+  }
+}
+
+```
+
+Adaptors
+--------
+
+
+An *adaptor* is a class template which builds on
+ another type or types to provide a new interface or behavioral
+ variant. Examples of standard adaptors are [std::reverse\_iterator](http://en.cppreference.com/w/cpp/iterator/reverse_iterator),
+ which adapts an iterator type by reversing its motion upon
+ increment/decrement, and [std::stack](http://en.cppreference.com/w/cpp/container/stack) , which adapts a container to provide a simple stack
+ interface.
+
+
+A more comprehensive review of the adaptors in the standard
+ can be found [here](http://portal.acm.org/citation.cfm?id=249118.249120).
+
+
+Type
+ Generators
+----------------
+
+
+**Note:** The *type generator* concept has
+ largely been superseded by the more refined notion of a
+ [metafunction](/doc/libs/release/libs/mpl/doc/refmanual/metafunction.html).
+ See *[C++
+ Template Metaprogramming](http://www.boost-consulting.com/mplbook/)* for an in-depth discussion of
+ metafunctions.
+
+
+A *type generator* is a template whose only purpose is
+ to synthesize a new type or types based on its template
+ argument(s)[[1]](#footnote1). The generated type is
+ usually expressed as a nested typedef named, appropriately
+ `type`. A type generator is usually used to
+ consolidate a complicated type expression into a simple one.
+ This example uses an old version of [`iterator_adaptor`](/doc/libs/release/libs/iterator/doc/iterator_adaptor.html) whose design didn't allow derived
+ iterator types. As a result, every adapted iterator had to be a
+ specialization of `iterator_adaptor` itself and
+ generators were a convenient way to produce those types.
+```
+
+template <class Predicate, class Iterator, 
+    class Value = *complicated default*,
+    class Reference = *complicated default*,
+    class Pointer = *complicated default*,
+    class Category = *complicated default*,
+    class Distance = *complicated default*
+         >
+struct filter\_iterator\_generator {
+    typedef iterator\_adaptor<
+        
+        Iterator,filter\_iterator\_policies<Predicate,Iterator>,
+        Value,Reference,Pointer,Category,Distance> **type**;
+};
+
+```
+
+Now, that's complicated, but producing an adapted filter
+ iterator using the generator is much easier. You can usually
+ just write:
+```
+
+boost::filter\_iterator\_generator<my\_predicate,my\_base\_iterator>::type
+
+```
+
+Object
+ Generators
+------------------
+
+
+An *object generator* is a function template whose only
+ purpose is to construct a new object out of its arguments.
+ Think of it as a kind of generic constructor. An object
+ generator may be more useful than a plain constructor when the
+ exact type to be generated is difficult or impossible to
+ express and the result of the generator can be passed directly
+ to a function rather than stored in a variable. Most Boost
+ object generators are named with the prefix
+ "`make_`", after `std::[make\_pair](http://en.cppreference.com/w/cpp/utility/pair/make_pair)(const T&, const U&)`.
+
+
+For example, given:
+```
+
+struct widget {
+  void tweak(int);
+};
+std::vector<widget \*> widget\_ptrs;
+
+```
+
+By chaining two standard object generators,
+ `std::[bind2nd](http://en.cppreference.com/w/cpp/utility/functional/bind12)()`
+ and `std::[mem\_fun](http://en.cppreference.com/w/cpp/utility/functional/mem_fun)()`,
+ we can easily tweak all widgets:
+```
+
+void tweak\_all\_widgets1(int arg)
+{
+   for\_each(widget\_ptrs.begin(), widget\_ptrs.end(),
+      **bind2nd**(std::**mem\_fun**(&widget::tweak), arg));
+}
+
+```
+
+Without using object generators the example above would look
+ like this:
+```
+
+void tweak\_all\_widgets2(int arg)
+{
+   for\_each(struct\_ptrs.begin(), struct\_ptrs.end(),
+      **std::binder2nd<std::mem\_fun1\_t<void, widget, int> >**(
+          std::**mem\_fun1\_t<void, widget, int>**(&widget::tweak), arg));
+}
+
+```
+
+As expressions get more complicated the need to reduce the
+ verbosity of type specification gets more compelling.
+
+
+Policy Classes
+--------------
+
+
+A policy class is a template parameter used to transmit
+ behavior. An example from the standard library is
+ `std::[allocator](http://en.cppreference.com/w/cpp/memory/allocator)`,
+ which supplies memory management behaviors to standard [containers](http://en.cppreference.com/w/cpp/container).
+
+
+Policy classes have been explored in detail by [Andrei Alexandrescu](http://www.moderncppdesign.com/) in
+ [this
+ chapter](http://www.informit.com/articles/article.aspx?p=167842) of his book, *Modern C++ Design*. He
+ writes:
+> 
+> In brief, policy-based class design fosters assembling a
+>  class with complex behavior out of many little classes
+>  (called policies), each of which takes care of only one
+>  behavioral or structural aspect. As the name suggests, a
+>  policy establishes an interface pertaining to a specific
+>  issue. You can implement policies in various ways as long as
+>  you respect the policy interface.
+> 
+> 
+> Because you can mix and match policies, you can achieve a
+>  combinatorial set of behaviors by using a small core of
+>  elementary components.
+> 
+> 
+> 
+
+
+Andrei's description of policy classes suggests that their
+ power is derived from granularity and orthogonality.
+ Less-granular policy interfaces have been shown to work well in
+ practice, though. [This paper](http://svn.boost.org/svn/boost/tags/release/Boost_1_30_2/boost/libs/utility/iterator_adaptors.pdf) describes an old version of [`iterator_adaptor`](/doc/libs/release/libs/iterator/doc/iterator_adaptor.html) that used non-orthogonal policies.
+ There is also precedent in the standard library: [`std::char_traits`](http://en.cppreference.com/w/cpp/string/char_traits), despite its name, acts as a
+ policies class that determines the behaviors of [std::basic\_string](http://en.cppreference.com/w/cpp/string/basic_string).
+
+
+Notes
+-----
+
+
+[1] Type generators
+ are sometimes viewed as a workaround for the lack of
+ “templated typedefs” in C++.
+
+
+
+
+
+
+
+
+

community/groups.html

@@ -0,0 +1,280 @@
+---
+title: Boost Mailing Lists
+copyright: Beman Dawes, David Abrahams, 2001-2005.
+revised: 
+---
+
+
+Boost Mailing Lists
+
+
+
+Boost Mailing Lists (A.K.A. Discussion Groups)
+==============================================
+
+The mailing lists are the heart of the Boost community. You
+ may read the lists via full-content email or email digests.
+Before Posting
+--------------
+
+
+**Read the [Discussion Policy
+ and Guide to Effective Posting](policy.html).** Doing so will
+ help you to ensure that your post is read by the people who
+ can help you and received in the spirit in which it was
+ intended.
+
+
+**Subscribe your posting address.** As an
+ anti-spam measure, postings to most Boost mailing lists will
+ only be accepted if the posting's "From:" header contains an
+ email address that is subscribed to the list. If you try to
+ post from an address that isn't subscribed, you will probably
+ get a message that says:
+> 
+> You are not allowed to post to this mailing list,
+>  and your message has been automatically rejected. If you
+>  think that your messages are being rejected in error,
+>  contact the mailing list owner at *list
+>  administrator's email address*.
+> 
+> 
+> 
+
+
+If you need to post from multiple email addresses, you
+ should subscribe to each one separately. You can configure your
+ subscription settings for any address to disable mail
+ delivery via each mailing list's web interface.
+* [Users](#users)
+* [Developers](#main)
+	+ [Archives](#archive)
+* [Announce](#announce)
+* [Interest](#interest)
+* [Project-Specific](#projects)
+	+ [Boost.Build](#jamboost)
+	+ [Boost CMake](#cmake)
+	+ [Python C++-Sig (for
+	 Boost.Python)](#cplussig)
+	+ [Language Binding](#langbinding)
+	+ [Boost.MPI Development](#mpi)
+	+ [Boost.Spirit](#spirit)
+	+ [Boost.Documentation](#boostdocs)
+	+ [Testing](#testing)
+	+ [Boost.uBlas (numerics)](#ublas)
+	+ [Boost.Thread](#thread)
+	+ [Translation Groups](#translation)
+* [#boost IRC channel](#IRC)
+
+
+Boost Users mailing list
+------------------------
+
+
+This list is oriented toward casual users of the Boost
+ libraries. It is a good place to start if you are having
+ trouble getting started with Boost or its individual libraries.
+ Feel free to post both "newbie" and more challenging questions,
+ but please check first to see if there's an appropriate
+ [Project-Specific](#projects) list; you'll often get
+ better answers in a forum dedicated to your problem area. This
+ list is relatively low volume (less than 500 per month).
+ Subscribe or unsubscribe at the [Boost Users list home page](https://lists.boost.org/mailman/listinfo.cgi/boost-users).
+
+
+Boost developers mailing list
+-----------------------------
+
+
+This is the main Boost mailing list. It is high volume (over
+ 1000 messages per month), very technical, and oriented toward
+ Boost library developers. It is also read by many other members
+ interested in watching the Boost library development process.
+ Virtually all Boost decisions, major or minor, technical or
+ otherwise, are reached via public discussion on this mailing
+ list. It is where the formal reviews of proposed libraries take
+ place. Subscribe or unsubscribe at <https://lists.boost.org/mailman/listinfo.cgi/boost>.
+
+
+When we talk about the "members of Boost", we are talking
+ about those signed up for this main mailing list.
+
+
+### Archives for Boost
+ developers list
+
+
+Archives of Boost messages include the [MailMan Archive](https://lists.boost.org/Archives/boost/) on [our home
+ page](/).
+
+
+Boost Announce mailing
+ list
+----------------------------
+
+
+This is an announce-only list for notification of upcoming
+ software releases and formal reviews of proposed libraries. One
+ to three messages per month.  Subscribe or unsubscribe at
+ the [Boost Announce list home page](https://lists.boost.org/mailman/listinfo.cgi/boost-announce).
+
+
+Boost Interest Mailing
+ List
+----------------------------
+
+
+This list is a moderated low-traffic announcement-only list
+ of interest to the Boost community. On-topic messages will
+ include announcements of books, magazine articles, papers,
+ talks, seminars, products, tools, events, or conferences on
+ advanced uses of C++, generic/generative/meta-programming, and,
+ of course, the Boost libraries. Off-topic will be discussion of
+ any kind. Job postings are accepted at the moderators'
+ discretion. Subscribe or unsubscribe at the [Boost-Interest home page](https://lists.boost.org/mailman/listinfo.cgi/boost-interest).
+
+
+Project-Specific
+ lists
+-----------------------
+
+Several mailing lists have been established for
+ specific Boost projects:
+
+ ### Boost.Build list
+
+
+The mailing list for the [Boost
+ Build System](../build/) is located [here](https://lists.boost.org/mailman/listinfo.cgi/boost-build).
+
+
+### Boost CMake list
+
+
+Development of the experimental [CMake build
+ system](http://svn.boost.org/trac/boost/wiki/CMake) is being coordinated on the [Boost
+ CMake mailing list](https://lists.boost.org/mailman/listinfo.cgi/boost-cmake). Any questions about CMake should be
+ asked here and not on the main Boost.Build list.
+
+
+### Python C++-Sig (for
+ Boost.Python)
+
+
+The [Python C++-sig](http://www.python.org/community/sigs/current/c++-sig/) is not strictly Boost-specific,
+ but nearly all the traffic concerns [Boost.Python](/doc/libs/release/libs/python). See also the
+ [Language Binding](#langbinding) list below. You can
+ join the [mailing list](http://mail.python.org/mailman/listinfo/cplusplus-sig "Python C++-sig mailing list"). There are
+ also searchable archives at [ASPN](http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/cpp-sig).
+
+
+### Language
+ Binding
+
+
+The [Language Binding](http://lists.sourceforge.net/lists/listinfo/boost-langbinding) list is for discussion of
+ a generalized framework for binding C++ to other languages and
+ systems based on the technology of [Boost.Python](/doc/libs/release/libs/python) and [Luabind](http://luabind.sourceforge.net/).
+ The plan is to provide a single front-end for describing
+ bindings with runtime-pluggable back ends for binding to
+ specific languages.
+
+
+### Boost.MPI Development
+
+
+A separate developer mailing list for [Boost.MPI](/doc/libs/release/libs/mpi/) specific topics is
+ located [here](https://lists.boost.org/mailman/listinfo.cgi/boost-mpi).
+
+
+### Boost.Spirit lists
+
+
+Spirit has two additional mailing lists. [Spirit-general](https://lists.sourceforge.net/lists/listinfo/spirit-general) for Spirit users and
+ [Spirit-devel](https://lists.sourceforge.net/lists/listinfo/spirit-devel) for Spirit developers (open
+ to anyone who wishes to hang out with Spirit coders).
+
+
+### Boost.Documentation
+ list
+
+
+The mailing list for the [Boost Documentation
+ System](/doc/libs/release/doc/html/boostbook.html) is located [here](https://lists.boost.org/mailman/listinfo.cgi/boost-docs).
+
+
+### uBLAS development
+ (ublas-dev) list
+
+
+A separate user and developer mailing list for [Boost
+ uBLAS](/doc/libs/release/libs/numeric/ublas/doc/) specific topics is located [here](https://lists.boost.org/).
+
+
+### Thread development
+ (threads-devel) list
+
+
+A separate developer mailing list for [Boost Thread](/doc/libs/release/libs/thread/doc/index.html)
+ specific topics is located [here](https://lists.boost.org/mailman/listinfo.cgi/threads-devel).
+
+
+**Important:** This mailing list is for the
+ discussion of the specification and implementation of
+ Boost.Threads only — questions regarding
+ usage should be directed to the [Boost
+ Users](#users) list, or the main [Boost
+ developers](#main) list.
+
+
+### Testing list
+
+
+The setup, procedures and tools necessary for running Boost
+ regression tests are discussed on [this list](https://lists.boost.org/mailman/listinfo.cgi/boost-testing). The list's main participants are
+ regression runners - people who run Boost tests on a variety of
+ compilers and platforms, and the maintainers of tools for
+ collecting and processing test results.
+
+
+**Important:** questions relevant to a wider audience,
+ including questions about Boost.Test framework or test results
+ for a particular library, should be posted to main development
+ list.
+
+
+### Translation
+ Groups
+
+
+Boost doesn't have the resources to translate the
+ documentation itself, but there is at least one separate group
+ translating the documentation. If you have formed another, tell
+ us on the [documentation list](#boostdocs) and we'll
+ add a link.
+
+
+* [Chinese
+ translators group](http://groups.google.com/group/boost_doc_translation) ([main
+ webpage](http://code.google.com/p/boost-doc-zh/))
+
+
+#boost IRC channel
+------------------
+
+
+In addition to the mailing lists presented above, a #boost
+ IRC channel on [freenode](http://freenode.net) is
+ frequented by Boost developers and users. As usual with IRC
+ channels, one should not necessarily expect that his questions
+ will be answered right away. The channel is not strictly
+ moderated.
+
+
+
+
+
+
+
+
+

community/gsoc.html

@@ -0,0 +1,161 @@
+---
+title: Boost C++ Libraries
+copyright: David Bellot 2020, Rene Rivera 2007.
+revised: 
+---
+
+
+Boost C++ Libraries
+
+
+
+Boost C++ Libraries
+===================
+
+Since 2005, Boost has participated in the Google [Summer of Code™](https://summerofcode.withgoogle.com/),
+ initiative, a program in which student developers are sponsored
+ for their contributions within open source organizations that are
+ willing to mentor the participants.
+
+
+Currently the application process begins around
+ March/April by the student
+ [reviewing past GSoC 
+ project ideas](#HistoricalGSoCIdeaspagesforyears2006tonow) and approaching the [Boost
+ developers mailing list](https://www.boost.org/community/groups.html#main) to find a mentor willing to mentor
+ them and codevelop a project proposal to be submitted to Google
+ for funding the upcoming summer. Students are expected to be
+ flexible with regard to what topics and proposals mentors are
+ willing to mentor.
+
+
+If you arrive at the process too late to prearrange a mentor,
+ some potential mentors supply prewritten project proposals with
+ C++ programming competency tests on [this year's GSoC Project Ideas page](https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code%3A-Overview). If you have in the past
+ made a **substantial** contribution to a well known open source project or participated in previous editions of the GSoC, it may be
+ possible to skip submission of the C++ programming competency test solution (decided on a case by case basis).
+
+
+Submit the competency test solution as part of the project proposal
+ you will submit to the Google Summer of Code program. You can copy and
+ paste relevant parts of your code or you can include links to, for example,
+ GitHub repository with your solution project.
+ 
+
+
+### Google Summer of Code 2020 overview
+This year, in 2020, 10 students will work with us on improving and adding new features to many of our libraries.
+
+Once again, the competition has been very hard. A few numbers:
+- we received 93 proposals in total. 85 of them were complete, then we kept 47 proposals only
+- finally we selected 10 of them, covering 7 different Boost libraries
+- and countless hours of work from the most incredible team of mentors!
+
+Here is the list of projects for 2020:
+
+#### Boost.Real
+
+
+* Kishan Shukla will be working on making the Real library ready for revision. His main goal is to reimplement the division algorithm so it can be used with any number base representation and the Karatsuba multiplication algorithm. Also, it will be working on implementing some operators and common irrational numbers as Pi.
+ *Mentors*: Laouen Belloli and Damian Vicino.
+
+
+#### Boost.Astronomy
+
+
+* Syed Ali Hasan will be working on the astronomical coordinate system, he will implement different coordinate conversion using SOFA library
+ *Mentor*: Pranam Lashkari
+* Gopi Krishna Menon will be completing the parser for FITS file and also optimise the already developed components.
+ *Mentor*: Sarthak Singhal
+
+
+#### Boost.GIL
+
+
+* Debabrata Mandal will be implementing histogram computation as a built-in feature, algorithms for histogram analysis, 
+ image processing algorithms based on histogram and possibly integration with Boost.Histogram library.
+  *Mentors*: Mateusz Loskot, Pranam Lashkari
+* Olzhas Zhumabek will be extending GIL's portfolio of image processing algorithms, implementing for image scaling and
+ sampling, Perona–Malik diffusion, Non-Maximum Suppression for object detection, Hysteresis threshold and some more.
+ *Mentor*: Mateusz Loskot
+
+
+**Boost.Multiprecision**
+
+
+* Dimitris Los will work on extending and optimizing parts of Boost.Multiprecision to higher precision of many thousands of bits or more.
+ *Mentor*: Christopher Kormanyos
+
+
+#### Boost.uBlas
+
+
+* Ashar Khan will stabilize and improve Boost.uBlas using the C++20-Standard. The main focus of his project will be enhancing code-coverage and documentation,
+ integrating static code analysis and generating tensor concepts.
+ *Mentor*: Cem Bassoy
+* Tom Kwok will improve and finalize the implementation of data frames in uBlas, with the aim of delivering production-ready by the end of the summer.
+ Data frames in uBlas are similar in functionalities to other implementations like in R, Python.Pandas or Julia.
+ *Mentor*: David Bellot
+
+
+#### Boost.Geometry
+
+
+* Tinko Bartels will work on robust yet efficient geometric predicates for Boost Geometry.
+ *Mentor*: Vissarion Fisikopoulos
+
+
+#### Boost.Real
+
+
+* Vikram Singh Chundawat will work in taking Real to revision ready state. His focus will be in improving the internal representation datatypes 
+ and providing functions required to conveniently support Taylor series.
+ *Mentors*: Damian Vicino and Laouen Belloli
+
+
+### Github's for standalone GSoCs past and present
+Since 2013 with Boost's transition to git we have kept a single umbrella org on github for those GSoCs which are fairly self standing. Incremental extensions to existing libraries usually enter that library's main git repo as an experimental branch. Here are those orgs:
+* GSoC 2020: <https://github.com/BoostGSoC20>
+* GSoC 2019: <https://github.com/BoostGSoC19>
+* GSoC 2018: <https://github.com/BoostGSoC18>
+* GSoC 2017: <https://github.com/BoostGSoC17>
+* GSoC 2015: <https://github.com/BoostGSoC15>
+* GSoC 2014: <https://github.com/BoostGSoC14>
+* GSoC 2013: <https://github.com/BoostGSoC13>
+
+
+Students may find examining past GSoC source code and commit histories of use.
+### Historical GSoC Ideas pages for years 2006 to now
+
+
+* 2020 [Project Ideas](https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code:-2020)
+* 2019 [Project Ideas](https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code:-2019)
+* 2018 [Project Ideas](https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code:-2018)
+* 2017 [Project Ideas](https://svn.boost.org/trac/boost/wiki/SoC2017)
+* 2016 [Project Ideas](https://svn.boost.org/trac/boost/wiki/SoC2016)
+* 2015 [Project Ideas](https://svn.boost.org/trac/boost/wiki/SoC2015)
+* 2014 [Project Ideas](https://svn.boost.org/trac/boost/wiki/SoC2014)
+* 2013 [Project Ideas](https://svn.boost.org/trac/boost/wiki/SoC2013)
+* 2012 [Project Ideas](https://svn.boost.org/trac/boost/wiki/SoC2012)
+* 2011 [Project Ideas](https://svn.boost.org/trac/boost/wiki/SoC2011)
+* 2010 [Project Ideas](https://svn.boost.org/trac/boost/wiki/SoC2010)
+* 2009 [Project Ideas](https://svn.boost.org/trac/boost/wiki/soc2009)
+* 2008  [Project Ideas](http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summer_Of_Code_2008)
+* 2007  [Project Ideas](http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summer_Of_Code_2007)
+* 2006  [Project Ideas](http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summer_Of_Code_2006).
+[An overview of Boost participation in Google Summer of Code™ 2006](https://www.boost.org/community/gsoc_2006_boost_overview.html).
+
+
+### Sponsorships
+
+
+* [IMC Financial Markets, 2016](imc_summer_of_code_2016.html)
+
+
+
+
+Revised $Date: 2020-05-12$
+
+
+
+

community/gsoc_2006_boost_overview.html

@@ -0,0 +1,823 @@
+---
+title: An overview of Boost participation in Google Summer of Code™  2006
+copyright: 
+revised: 2007-10-22 22:55:52 +0100
+---
+
+
+An overview of Boost participation in Google Summer of Code™
+ 2006
+
+
+/\*<![CDATA[\*/
+ blockquote.c3 {FONT-SIZE: 75%;}
+ td.c2 {text-align:center}
+ th.c1 {text-align:left}
+ /\*]]>\*/
+ 
+
+
+An overview of Boost participation in Google Summer of
+ Code™ 2006
+==================================================================
+
+For the second consecutive year, Google has conducted its
+ [Summer of Code™](http://code.google.com/soc/)
+ initiative, a program by which student developers are sponsored
+ for their contributions within open source organizations
+ willing to mentor the participants. The 2006 campaign has run
+ between April and September, with active development work
+ taking place between May 23 and August 21.
+
+
+Around mid April, when the program had just started, some
+ Boost members began considering the possibility to enter Summer
+ of Code as a mentoring organization. Despite the lack of time
+ and the fact that most of us were completely new to this
+ initiative, Boost managed to successfully apply for the
+ program. As a result ten projects were selected and mentored,
+ most of which are expected to become full contributions to
+ Boost shortly.
+
+
+We give here a summary report of this experience, along with
+ a short analysis of the main problems we found, so that we can
+ work at solving them and do better next year.
+
+
+Contents
+--------
+
+
+* [How the program works](#how_the_program_works)
+	+ [2006 figures](#figures_2006)
+* [Boost participation](#boost_participation)
+	+ [Application and
+	 process selection](#application_and_process_selection)
+	+ [Accepted
+	 projects](#accepted_projects)
+	+ [Development](#development)
+	+ [Results](#results)
+* [Analysis](#analysis)
+	+ [Boost appeal](#boost_appeal)
+	+ [Opportunities
+	 lost?](#opportunities_lost)
+	+ [Projects startup](#projects_startup)
+	+ [Ongoing
+	 development](#ongoing_development)
+	+ [Public
+	 communication issues](#public_communication_issues)
+	+ [Scope of
+	 projects](#scope_of_projects)
+* [Suggestions for
+ improvement](#suggestions_for_improvement)
+	+ [Preparation](#preparation)
+	+ [Public
+	 communication](#public_communication)
+	+ [Project
+	 management](#project_management)
+* [Conclusions](#conclusions)
+* [Acknowledgements](#acknowledgements)
+
+
+How the program works
+---------------------
+
+
+There are three types of participants in Google Summer of
+ Code:
+
+
+* Google itself acts as the funding partner and conducts
+ the overall program.
+* The open-source organizations accepted into the program
+ must designate people inside the organization who will act as
+ project mentors.
+* Students submit their project ideas and, if selected,
+ work in collaboration with one of the mentoring
+ organizations; upon successful completion of the project,
+ students receive the full stipend for the program.
+
+
+The program goes through the following stages:
+
+
+* Organization selection: those open source organizations
+ willing to enter Summer of Code submit an expression of
+ interest to Google, along with information Google uses for
+ qualifying purposes. Selected organizations are publicly
+ announced and each organization is expected to provide a pool
+ of project ideas.
+* Student selection: students willing to participate submit
+ one or more project proposals, typically expanding on some of
+ the ideas previously provided by the mentoring organizations.
+ A student can apply several times and for different
+ organizations, but ultimately can only be chosen for just one
+ project. These proposals are routed by Google to the
+ appropriate organizations, which must analyze them, rank
+ them, and assign mentors to the most promising applications.
+ Based on the information provided by mentoring organizations,
+ Google issues the final list of accepted projects.
+* Development: Students, guided by their assigned mentors,
+ are expected to complete the projects during a period of three
+ months. Google asks mentors for a mid-program review upon
+ which continuation of the project depends.
+* Final review: Once the development period is over,
+ mentors are requested to inform Google of the results of the
+ project, and determine whether students qualify to receive
+ the full stipend.
+
+
+### 2006
+ figures
+
+
+The 2006 campaign of Google Summer of Code took place
+ between April 14 and September 25. A total of 102 mentoring
+ organizations participated. Of the 6,338 applications submitted
+ by 3,044 students around the globe, 630 were finally selected
+ and funded. Google has spent more than US$3 million in student
+ stipends and compensations to the mentoring organizations.
+
+
+Boost participation
+-------------------
+
+
+### Application and process
+ selection
+
+
+On April 14, the same day Google Summer of Code started,
+ Julio M. Merino Vidal (later to become one of the selected
+ students) sent a message encouraging Boost members to
+ participate in this program as a mentoring organization. This
+ call sparked the interest of the community; although time was
+ already short for doing all the preparation labors, Boost
+ moderators put rapidly themselves to work and conducted the
+ preliminary registration steps. In the meantime, a Wiki page
+ was grown with project ideas provided by Boost members,
+ totaling more than twenty proposals.
+
+
+By the beginning of May Boost was officially accepted into
+ the program and Boost moderators set out to form a group of
+ mentors, selected on an invitation basis. As student selection
+ is a delicate process, involving the assessment of individuals
+ on their technical skills, all subsequent discussions were
+ conducted by the selected mentors on a private mail list
+ established for their collaboration.
+
+
+We were not prepared for the avalanche of student
+ applications that followed. On day two after the application
+ period was open, we had received three proposals; the next day it
+ was 14, and within a week the count exceeded 50. By the end of
+ the application period the total number of proposals received
+ was 174, which forced us to go through a very intensive ranking
+ process and recruit additional mentors. Two rules were followed
+ so as rationalize the process of selection among dozens of
+ different proposals:
+
+
+* Where there were competing applications for the same
+ project idea, only one were to be ultimately selected; so, no
+ two projects with the same or very similar goals were
+ accepted.
+* Some of the applications built on a given Boost library
+ (for instance, the Boost Graph Library is a frequent target
+ for the addition of algorithms.) We limited the applications
+ to a maximum of two per Boost library.
+
+
+These rules have the combined effect of greatly reducing the
+ number of eligible applications while at the same time
+ distributing the accepted projects evenly across the space of
+ ideas. Moreover, students with unique proposals, i.e. project
+ ideas not coming from the pool originally presented by Boost,
+ are at a competitive advantage.
+
+
+The different proposals were classified according to their
+ related technological area so that each cluster could be
+ handled by an appointed mentor with the required expertise on
+ the subject. Mentors submitted then "focus reports" summarizing
+ the applications under their responsibility; these reports
+ served as a first filter to help reduce the number of final
+ applications to be evaluated jointly. Along the process,
+ students with the most promising proposals were asked to refine
+ their ideas and provide further information.
+
+
+Although not enforced by the official rules, we agreed upon
+ a one-to-one ratio of mentors to students, which ultimately
+ marked a hard limit on the maximum number of eligible
+ projects.
+
+
+### Accepted projects
+
+
+Google accepted and funded the ten top-ranked projects
+ endorsed by Boost. Of these, eight projects are libraries or
+ library components targeted for future inclusion into Boost,
+ while the remaining two consist of utility programs heavily
+ relying on Boost.
+> 
+> **C++ Coroutine Library**  
+> 
+>  Giovanni Piero Deretta, mentored by Eric Niebler.  
+> 
+>  Library for the management through a modern C++ interface of
+>  OS-provided coroutine facilities.
+> 
+> 
+> 
+> 
+> **Concurrency Library**  
+> 
+>  Matthew Calabrese, mentored by David Abrahams.  
+> 
+>  STL-inspired generic framework for high-level specification
+>  and execution of parallelizable algorithms.
+> 
+> 
+> 
+> 
+> **TR1 Math Special Functions**  
+> 
+>  Xiaogang Zhang, mentored by John Maddock.  
+> 
+>  Implementation of the 23 special mathematical functions
+>  specified in C++ standard library extension proposal TR1.
+> 
+> 
+> 
+> 
+> **The Boost.Process library**  
+> 
+>  Julio M. Merino Vidal, mentored by Jeff Garland.  
+> 
+>  Portable library for process launching and basic
+>  management.
+> 
+> 
+> 
+> 
+> **Out-of-Core Graphs and Graph
+>  Algorithms**  
+> 
+>  Stéphane Zampelli, mentored by Jeremy Siek.  
+> 
+>  Extension of the Boost Graph Library to deal with out-of-core
+>  structures, i.e. data sets too large to be kept in main
+>  memory at once.
+> 
+> 
+> 
+> 
+> **MISC (M)ulti (I)ndex (S)pecialized
+>  (C)ontainers**  
+> 
+>  Matías Capeletto, mentored by Joaquín M
+>  López Muñoz.  
+> 
+>  Families of specialized containers internally based on
+>  Boost.MultiIndex.
+> 
+> 
+> 
+> 
+> **Generic Tree Container**  
+> 
+>  Bernhard Reiter, mentored by René Rivera.  
+> 
+>  Design and implementation of a family of STL-compatible tree
+>  containers.
+> 
+> 
+> 
+> 
+> **Viewer utility for FSMs**  
+> 
+>  Ioana Tibuleac, mentored by Andreas Huber Dönni.  
+> 
+>  Utility program for the visualization of finite state
+>  machines (FSMs) specified with Boost.Statechart.
+> 
+> 
+> 
+> 
+> **Modular C++ preprocessor, using
+>  Boost.Spirit**  
+> 
+>  Hermanpreet 'Lally' Singh, mentored by Joel de Guzman.  
+> 
+>  Implementation with Boost.Spirit and Boost.Wave of a
+>  front-end translator from Modular C++ (as specified in a
+>  proposal to add modules to C++ by Daveed Vandevoorde) to
+>  standard C++.
+> 
+> 
+> 
+> 
+> **Implementing a state of the art Mincut/Maxflow
+>  algorithm.**  
+> 
+>  Stephan Diederich, mentored by Douglas Gregor.  
+> 
+>  Implementation of a fast mincut/maxflow routine for the Boost
+>  Graph Library based on a new algorithm devised by Vladimir
+>  Kolmogorov.
+> 
+> 
+> 
+
+
+### Development
+
+
+Two main facilities were set up to assist students and
+ mentors during the development phase: a mailing list and a
+ Trac/SVN project management system with separate directories
+ for each project. One of the students, Matí as Capeletto,
+ out of personal initiative registered a Google Group aimed at
+ giving students with Boost a place for informal interaction and
+ discussion of common problems.
+
+
+After the initial warm-up period, each student-mentor pair
+ performed development work mostly privately. The usage of the
+ Boost mailing lists was scarce, and only by the end of the
+ program did some students publicly announced their results.
+
+
+### Results
+
+
+By the date the development period was officially closed,
+ the status of the different projects was as follows:
+
+
+* Seven projects were completed or nearly completed and the
+ students are expected to ask for a formal review within 2006
+ or early 2007. Four of these projects necessitated a goal
+ reorientation during development, basically because the
+ original plan was too ambitious for three months. Most of the
+ projects are still in active development during the months
+ following the Summer of Code program.
+* Two projects did not reach the planned goals, but
+ nevertheless produced useful material that could be expanded
+ outside of the Summer of Code program.
+* One project was abandoned shortly after the midterm
+ review. The reasons for the abandonment are unknown.
+
+
+The results of all the projects can be consulted online at
+ the dedicated [Trac
+ site](http://svn.boost.org/trac/boost/browser/sandbox/SOC/2006).
+
+
+Analysis
+--------
+
+
+We examine the various stages of Boost participation in
+ Summer of Code, with an emphasis on discovering opportunities
+ for improvement.
+
+
+### Boost
+ appeal
+
+
+In a mid project [presentation
+ at OSCON 2006](http://code.google.com/soc/GSoC2006Statistics.pdf), Chris DiBona from Google provided some data
+ about the organizations which received the most
+ applications:
+
+| Organization | No of applications |
+| --- | --- |
+| KDE | 244 |
+| Ubuntu & Bazaar | 236 |
+| Python Software Foundation | 212 |
+| GNOME | 199 |
+| Apache Software Foundation | 190 |
+| **Boost** | **174** |
+| Gaim | 152 |
+| The GNU Project | 148 |
+| Drupal | 146 |
+> 
+> The numbers shown here have been estimated from a chart
+>  included in the presentation slides. This chart contains an
+>  additional column labeled "Google" which actually accounts
+>  for the applications dismissed because of their low
+>  quality.
+> 
+> 
+> 
+
+
+The fact that Boost is ranked the sixth most attractive
+ organization out of a total of 102 was entirely unexpected,
+ especially considering the wide popularity of the rest of
+ top-rated organizations. There is a more or less implicit
+ consensus among Boost members that ours is a relatively niche
+ project, known for its quality standards by seasoned C++
+ practitioners, but with a limited penetration among entry level
+ programmers: maybe the figures above should make us reconsider
+ this assumption. A cursory examination of the applications
+ submitted to Boost reveals that most applicants were regular
+ users of Boost: many cite the Boost status among the C++
+ community as an appealing factor to apply.
+
+
+### Opportunities lost?
+
+
+If we look at the number of funded projects concerning
+ the applications received, figures are not so favorable to
+ Boost.
+
+| Organization | No of projects | Project/app ratio |
+| --- | --- | --- |
+| KDE | 24 | 9.8 % |
+| Ubuntu & Bazaar | 22 | 9.3 % |
+| Python Software Foundation | 23 | 10.8 % |
+| GNOME | 19 | 9.5 % |
+| Apache Software Foundation | 27 | 14.2 % |
+| **Boost** | **10** | **5.7 %** |
+| Gaim | 8 | 5.3 % |
+| The GNU Project | 10 | 6.8 % |
+| Drupal | 14 | 9.6 % |
+
+
+It turns out that the project/application ratio for almost
+ any other organization among the top nine is considerably
+ higher than that of Boost. As it happens, Google initially
+ requested that organizations submitted the maximum number of
+ projects they felt they could cope with, and we got funding for
+ exactly what we aimed for, so the limiting factor lies entirely
+ on Boost's side.
+
+
+### Projects startup
+
+
+Contributing to Boost relies on a fair number of guidelines
+ and protocols for coding, documentation, testing and
+ maintenance. Many of the required tools are exclusively used
+ within Boost, and some of them are not trivial, like for
+ instance Boost.Build. Although the Boost web site contains
+ information about all these tools and procedures, this
+ intelligence is scattered through unrelated pages and sometimes
+ is very hard to come by.
+
+
+So, there is a good deal of expertise required to begin
+ working at Boost. Some students have reported on startup
+ difficulties getting to know these details and familiarizing
+ themselves with the tools, most notably `bjam` and
+ Quickbook. Each student overcome the startup difficulties on
+ their own or resorting to their mentors (see the section on
+ [public communication
+ issues](#public_communication_issues)).
+
+
+### Ongoing development
+
+
+Once students got past the startup stage, most projects
+ advanced without serious complications. In the majority of
+ cases, it was realized at some point during the development
+ that there was no time to complete it. Some participants had to
+ redefine the goals to keep the project within
+ schedule, while others simply decided that they would continue
+ working after the official deadline of Summer of Code.
+
+
+The information flow between each student and their mentor
+ was usually reported by both parties to be satisfactory. The
+ projects suffering from lack of communication have been
+ precisely those yielding the poorest results. In general,
+ mentors have not felt overwhelmed by requests from their
+ students, and even in a couple of cases, the projects were run
+ practically unattended. This fact is witness to the high
+ competence of the students recruited into the program.
+
+
+The degree of usage of the Trac/SVN system has varied. Some
+ students did frequent updates, while others have just used the
+ repository to dump the final results for the official
+ submission to Google.
+
+
+### Public communication
+ issues
+
+
+Students and mentors had at their disposal three different
+ forums for the public interchange of information and
+ support:
+
+
+* Boost public lists, especially the developers and users
+ lists.
+* A dedicated mailing list reaching all students and
+ mentors working at Summer of Code in Boost.
+* A more casual Google Group, set up by one of the
+ students, aimed at providing the participants with a place
+ for socializing and resolution of common problems.
+
+
+Despite this abundance of resources, there was an almost
+ complete lack of group communication among all the parties
+ involved and between these and the larger Boost community.
+ Seemingly, students were satisfied to pursue their activities
+ by relying on support from their mentors alone. This
+ circumstance has prevented Boost members from enriching the
+ initiative by offering their experience and insight, and has
+ possibly led students to the false impression that contributing
+ to Boost proceeds in a predictable linear path from requisites
+ to completion of the work. When asked about their not engaging
+ in public communication, the students gave vague justifications
+ that can be classified into the following:
+
+
+* Doubts were deemed too technical or specific to be worth
+ raising in public.
+* A craving for perfectionism detracted students from asking
+ or submitting work in progress until they felt their material
+ looked good enough.
+* Shyness: some students probably lacked previous
+ experience communicating in public, and most are not English
+ native speakers, which could also be a limiting factor.
+
+
+Although students did not identify the following as a reason
+ not to go public, likely, many of them did not feel
+ the need given the ready access to their mentors they
+ enjoyed. It is easy to grow used to such a dedicated source of
+ support and neglect to resort to other resources. Mentors
+ should have encouraged their students to pursue the public
+ discussion of projects, which constitutes one of the pillars of
+ Boost renowned quality.
+
+
+### Scope of projects
+
+
+In hindsight, it has become apparent that most projects were
+ too ambitious to be completed within the three months of
+ duration of the program, and even those that were considered a
+ success will need weeks or months of polishing up before the
+ material is ready for a formal review. In contrast with other
+ organizations participating in the Summer of Code program,
+ Boost has as of this writing included no results into its codebase. No formal review for any project has been requested yet,
+ either.
+
+
+These scope issues are very dependent on the particular type
+ of project. We can classify the Boost projects for Summer of
+ Code as follows:
+
+
+* Full-fledged libraries,
+* additions to existing Boost libraries,
+* utilities and tool projects using Boost.
+
+
+Of these, additions (like for instance the max-flow min-cut
+ algorithm for BGL by Stephan Diederich) are the most suitable
+ for completion in a short period of time: most of the
+ preparation work is already done, and the student has clear
+ guides as to what coding and documentation standards to follow.
+ Also, these projects need not undergo a formal review, since it
+ is the responsibility of the hosting library author to review
+ the code and include it within her discretion. Utility projects
+ seem also suitable for small timeframes, though most project
+ proposals and requests are naturally oriented to contributions
+ of actual code to the Boost project.
+
+
+As for those projects involving the design and realization
+ of full-fledged libraries, there is little hope that the goals
+ and scope can be kept modest enough for a three-month schedule.
+ Boost candidate libraries developed by professional authors
+ usually take much longer than three months to be accepted; some
+ libraries have been evolving through several *years*
+ before being included in Boost. So, the best we can hope for
+ if we are to support the realization of library projects for
+ Boost inside Summer of Code is that the results by the end of
+ the program can be evaluated to constitute a viable
+ *potential* contribution to Boost. When this is the case,
+ it is crucial that the student commits to further working on
+ the project up to completion and formal review. Perhaps more
+ important than getting libraries coded is to engage new authors
+ in a long-term relationship with the Boost project.
+
+
+Suggestions for
+ improvement
+----------------------------
+
+
+The following proposals aim to alleviate some of the
+ problems we have identified during the development of Summer of
+ Code within Boost. These action points are related only to the
+ issues found in connection with Boost: we are not addressing
+ other areas of improvement associated with the Summer of Code
+ program itself.
+
+
+### Preparation
+
+
+Much work can be done before the actual program begins. The
+ following preparation activities can already be launched:
+
+
+**Create a pool of ideas for projects.** This
+ action will provide valuable extra time for evaluation and
+ refining of ideas before the Summer of Code begins. The
+ experience has shown that those projects with more preparation
+ work, especially in the area of design, were ultimately more
+ successful. The pool can also be used to retain interesting
+ ideas that arise on the mailing lists and very often are not
+ given proper attention and become abandoned.
+
+
+**Create a student pool.** Prior involvement
+ with Boost is an advantage both in the selection phase
+ and later during project development. Those students with a
+ serious interest in participating in Summer of Code with Boost
+ can enter the pool and begin exploring ideas and interacting
+ with the community well in advance of the summer, to put
+ themselves in a favorable position for the selection.
+ Advertisement for the student pool can be initiated in the
+ beginning of 2007 through the usual channels (web site and
+ mailing lists): additionally, Boost members involved with the
+ University can spread this information locally and help raise
+ the interest of students in their environment.
+
+
+**Create a mentor pool.** Given the rush with
+ which Boost entered the 2006 Summer of Code campaign, the
+ invitation of mentors has to be done on an on-demand basis as
+ it became all too evident that the task was growing bigger and
+ bigger. The organization must be better
+ prepared next year so that several people with the ability
+ and will to participate as Boost mentors are identified in
+ advance.
+
+
+**Prepare a startup package.** In order to
+ facilitate the initial period of getting familiarized with the
+ various Boost guidelines, protocols and tools, it would be
+ extremely useful to prepare a compilation of startup material
+ for students. This package can consist of a single document
+ gathering the currently dispersed information, or go beyond
+ this and provide some bundle of documentation and pre-built
+ tools, an approach that one of the students is currently
+ working on.
+
+
+### Public communication
+
+
+ students must get involved with the community
+ as soon as possible and grow to appreciate the advantages of
+ public development concerning solitary coding.
+
+
+**Mandate (bi)weekly reports.** These reports
+ should be directed to the public mailing lists to allow all Boost members to follow the work in progress
+ and contribute. Reporting has the extra benefit for students of
+ forcing them to reflect on their work periodically and
+ struggle with the often difficult task of presenting their
+ ideas to others.
+
+
+**Conduct student-mentor exclusively through public
+ channels.** This might be too drastic a policy, as some
+ matters need privacy and depending on the amount of
+ information exchanged flooding problems may arise. Less severe
+ variations involve allowing for some private interchange at the
+ mentors' discretion and moving this kind of communication to a
+ dedicated public mailing list different from the general
+ ones.
+
+
+### Project management
+
+
+The two most important issues to improve upon with respect
+ to the management are:
+
+
+* Project scope must be kept under control,
+* The progress has to be publicly visible, so that problems
+ of scope, design and/or schedule can be more easily
+ detected.
+
+
+Some of the proposals in this section are not to be regarded
+ as strict rules, but rather as general guidelines to be kept in
+ mind by students and encouraged by mentors.
+
+
+**Create a best practices document.** This
+ document can serve as a guideline for project management, an
+ area in which Boost traditionally imposes no requirements.
+ Students might lack the expertise in this area that is usually
+ taken for granted in the traditional model where contributions
+ to Boost are made by professional programmers.
+
+
+**Mandate a design phase.** Having a concrete
+ design set up and clearly described early in the project will
+ help estimate the necessary effort for completion of the work.
+ This is also an opportunity for public discussion.
+
+
+**Maintain code, docs and tests in parallel.**
+ All too often, novice programmers do the coding in one fell
+ swoop and only then move to testing and documenting their work.
+ This is unacceptable by all current methodology standards, and
+ can result in serious underestimations of the time to
+ completion.
+
+
+**Encourage the KISS principle.** It is much
+ better to finish a simpler library and then iteratively evolve
+ it, once it has been exposed to public scrutiny and usage.
+
+
+**More Trac updates.** The repository should be
+ viewed as an everyday work tool, not only as of the place into
+ which to dump the final results. Updating often leads to more
+ visibility of the work by the mentor and the public in
+ general.
+
+
+**Informal reviews.** The typical Summer of
+ Code Boost project will not be completed by the official
+ deadline, as have been discussed earlier. To somehow
+ officialize the work done within the Summer of Code proper, and
+ also to allow the students to reach some sort of psychological
+ milestone, informal reviews can be instituted where Boost
+ members evaluate the work done at the end of Summer of
+ Code.
+
+
+**Engage students.** This experience has shown
+ that it is possible to guide willing and bright students to the
+ competence levels required for contributing to Boost. The best
+ possible outcome of Summer of Code campaigns are the
+ incorporation of new people into the circle of Boost active
+ contributors. Strive to make the students commit to Boost.
+
+
+Conclusions
+-----------
+
+
+Despite the lack of previous experience in Boost, our
+ participation in Google Summer of Code has been extremely
+ fruitful: much useful material has been produced, and, perhaps
+ more importantly, some of the students are likely to commit on
+ a long-term basis and grow to be regular Boost contributors.
+ Traditionally, becoming a productive Boost author has a very
+ high entry barrier due to the extreme quality standards, lack
+ of public support and the very specific culture of the project.
+ The appeal of Summer of Code itself and the possibility of
+ being gently mentored into the world of Boost has most likely
+ been key factors in lowering this entry barrier.
+
+
+The process has not been without some difficulties, either,
+ as it was expected of a newcomer organization as Boost. We have
+ tried to identify in this paper the areas of improvement and
+ suggest specific actions so that the upcoming Google Summer of
+ Code 2007 can be an even more rewarding experience.
+
+
+Acknowledgements
+----------------
+
+
+This paper couldn't have been written without the numerous
+ reports and contributions kindly provided by Boost students and
+ mentors: Many thanks to all the participants for sharing their
+ experiences with me. Thank you also to the people at Google who
+ have promoted and conducted the Summer of Code initiative.
+
+
+
+
+
+
+© Copyright 2006 Joaquín M López
+ Muñoz.
+
+

community/imc_summer_of_code_2016.html

@@ -0,0 +1,58 @@
+---
+title: Boost C++ Libraries
+copyright: Jon Kalb 2016.
+revised: 
+---
+
+
+Boost C++ Libraries
+
+
+
+IMC Summer of Code 2016
+=======================
+
+[![IMC](../gfx/imc.png)](http://www.imc.com/)
+Boost has participated in the Google Summer of Code program
+ for a decade and is very grateful for Google's generous past
+ support. This program allows college students to have a paid
+ summer internship working on open source projects, giving them
+ an interesting alternative to summer onsite internships.
+ Because the students that work on Boost libraries tend to stay
+ with the same libraries summer after summer, the continuity of
+ this program is important to Boost and to the students that
+ work on Boost projects.
+
+
+Boost has traditionally been a model GSoC participant
+ receiving a more than average slot allocation, so we were
+ caught by surprise when Google rejected our 2016 application.
+ They asked us to apply again next year but to sit out 2016 to give open-source projects which don't normally get awarded
+ an opportunity. We understand this rationale, but this policy
+ would mean no summer internships for Boost and leave students
+ that have been working on Boost libraries looking for other
+ alternatives for the summer of 2016.
+
+
+When [IMC Financial Markets](http://www.imc.com/)
+ learned about this situation, they saw it as an opportunity to
+ support the Boost community and demonstrate their commitment to
+ student development and open source.
+
+
+IMC worked with Boost to create its own "Boost Summer of
+ Code" program, deliberately patterned after Google's program.
+ IMC also stepped up to underwrite all the costs of this program
+ for the summer of 2016.
+
+
+We thank IMC for their support and community leadership.
+
+
+
+
+
+
+
+
+

community/implementation_variations.html

@@ -0,0 +1,287 @@
+---
+title: Boost Implementation Variations
+copyright: Beman Dawes 2001.
+revised: 
+---
+
+
+Boost Implementation Variations
+
+
+
+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 that uses a lot
+ of memory versus a slower implementation which uses less
+ memory.
+
+
+Boost libraries generally use a [configuration
+ header](/doc/libs/release/libs/config/config.htm), 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 that 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 reasonable 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.
+
+
+
+
+
+
+
+
+

community/index.html

@@ -0,0 +1,50 @@
+---
+title: Community
+copyright: Rene Rivera 2007.
+revised: 
+---
+Community
+
+
+/\*<![CDATA[\*/
+ iframe.c1 {border: 0px none; }
+ /\*]]>\*/
+ 
+
+
+Community
+=========
+
+Although Boost was begun by members of the C++ Standards
+ Committee Library Working Group, participation has expanded to
+ include thousands of programmers from the C++ community at
+ large.
+
+
+If you are interested in participating in Boost, please join
+ our main [developers mailing
+ list](groups.html#main). Discussions are highly technical, and listed members
+ are encouraged to participate in formal reviews of proposed
+ libraries. There is also a [users
+ mailing list](groups.html#users), and several [project specific lists](groups.html#projects).
+
+
+If you are looking for more lively interaction with the
+ Boost community there are also some [internet
+ relay chat](irc.html) channels (freenode) that users and developers
+ like to hang out in.
+
+
+Below is a community maintained calendar of Boost related
+ events. Mostly, this includes development of the release. Note
+ that schedules slip and this might not be up to
+ date.
+
+
+
+
+
+
+
+
+

community/irc.html

@@ -0,0 +1,66 @@
+---
+title: Boost IRC Hangouts
+copyright: Rene Rivera 2007.
+revised: 
+---
+
+
+Boost IRC Hangouts
+
+
+
+Boost IRC Hangouts
+==================
+
+Boost users and developers spend time in various IRC
+ channels to generally work together. The attendance and traffic
+ of the channels vary greatly but there is usually someone
+ around to chat. And many times chat about just about any topic,
+ not just about the Boost C++ Libraries.
+
+
+Even though the channels are not moderated in the strict
+ sense, for some there is the expectation that one should follow
+ the usual Boost discussion rules of civility. This is both as a
+ recognition that the Boost community is varied in age, and in
+ sensibilities. So please keep your language clean. And don't be
+ surprised if you find yourself reprimanded by the ops.
+
+
+Our channels can be found on the [freenode](http://freenode.net/) network.
+
+
+#boost
+------
+
+
+This is the main channel, and as such sees a good deal of
+ traffic at times. Most times one can find about 80 "people"
+ (there are a few bots in there) and a good representation from
+ Boost developers. If you are looking for some quick help in
+ getting something in Boost working this is a good place to
+ go.
+
+
+* [Connect](irc://freenode/boost)
+
+
+##c++
+-----
+
+
+This is rather chatty but topical, hence the ## in the name,
+ C++ language discussion channel. Many of the same people who
+ hang out in the #boost channel, also hang out here.
+
+
+* [Connect](irc://freenode/%23%23c++)
+
+
+
+
+
+
+
+
+

community/moderators.html

@@ -0,0 +1,72 @@
+---
+title: Moderators
+copyright: Beman Dawes 2001-2004.
+revised: 
+---
+
+
+Moderators
+
+
+
+Boost Moderators
+================
+
+The Boost moderators are [Dave Abrahams](/users/people/dave_abrahams.html), Carl
+ Daniel, [Beman
+ Dawes](/users/people/beman_dawes.html), [Jeff
+ Garland](/users/people/jeff_garland.html), [Doug
+ Gregor](/users/people/doug_gregor.html), and [John
+ Maddock](/users/people/john_maddock.html). You can reach the moderators at [boost-owner@lists.boost.org](mailto:boost-owner@lists.boost.org).
+
+
+**Note:** The boost moderators do not moderate any
+ mailing lists other than the main Boost developers' list. For
+ example, the boost-users list moderators are at [boost-users-owner@lists.boost.org](mailto:boost-users-owner@lists.boost.org).
+ The moderators of [every other
+ Boost list](/community/groups.html) can be reached through its home page.
+
+
+Moderator Functions
+-------------------
+
+
+* Monitor the mailing list to ensure dialog remains within
+ the acceptable boundaries set by the [discussion policy](/community/policy.html). When
+ discussion strays, use private email to gently remind,
+ strongly rebuke, or outright ban, as the situation
+ demands.
+
+
+* Approve the initial postings of new (and thus still
+ moderated) members, and move members to the "Group Policy"
+ posting status.
+
+
+* Administer the internal operations of the Boost web site,
+ the main Boost mailing list, the CVS repository, and other
+ Boost administrative machinery.
+
+
+* Act as an executive committee overseeing important
+ administrative and policy decisions. Boost is a zero-budget
+ organization with no income and no expenses, so that
+ eliminates the need for most management. Technical decisions
+ are worked out on the mailing list. The moderators handle the
+ few remaining decisions that need a definite answer.
+
+
+* Beyond the purely administrative duties, work to keep the
+ Boost community vibrant and alive. That may be as simple as
+ saying "thank you" to an individual member, or as complex as
+ starting some major new initiative. Do whatever it
+ takes!
+
+
+
+
+
+
+
+
+

community/official_library_maintainer_program.html

@@ -0,0 +1,88 @@
+---
+title: Boost Library Official Maintainer Program
+copyright: Alex Olivas 2015.
+revised: 
+---
+
+
+Boost Library Official Maintainer Program
+
+
+/\*<![CDATA[\*/
+ body {font-family: sans-serif;}
+ /\*]]>\*/
+ 
+
+
+Boost Library Official Maintainer Program
+=========================================
+
+
+Introduction
+------------
+
+
+The [Boost Community Maintenance Team](https://svn.boost.org/trac/boost/wiki/CommunityMaintenance) (CMT) has identified many Boost 
+ libraries still used but not maintained actively. To protect the
+ reputation that Boost has cultivated over the years, as an
+ organization that provides high-quality open-source software,
+ all libraries bundled with Boost releases
+ have active and engaged maintainers. The purpose of the Boost
+ Library Official Maintainer Program is to recruit companies and 
+ organizations, that are likely already providing internal support, 
+ to become official maintainers of those libraries already important
+ to them. 
+
+
+In exchange for taking on maintenance of a library, Boost will 
+ display the maintainer's logo below in the [Libraries and Participants](#libraries_and_participants)
+ section. Boost may also display the logo on the Boost github 
+ and Trac sites. Maintainers are also allowed to use the [Boost Official Library
+ Maintainer Logo](blom_libraries/logos/blom_logo.png) on their own sites, presentations,
+ etc...
+
+
+Applying to the Program
+-----------------------
+
+
+If you're interested in maintaining a Boost library :
+
+
+1. Read the [Memorandum of
+ Understanding](blom_libraries/BLOM_MoU_v0.pdf), which outlines what's expected of
+ mainainers as well as terms for leaving the program.
+2. Send an email to the program administrator ([Alex Olivas](mailto:olivas@icecube.umd.edu)) indicating
+ which library (or libraries) you'd like to maintain.
+
+
+Thanks for helping out!
+
+
+Libraries and
+ Participants
+---------------------------
+
+
+[Boost.Function](blom_libraries/boost_function.html) -
+ Maintained by [The IceCube
+ Collaboration](http://www.icecube.wisc.edu) ![IceCube South Pole Neutrino Observatory](blom_libraries/logos/IceCube_horizontal2.jpg)
+
+
+### Program Administrator
+
+
+The Boost Library Official Maintainer Program is currently
+ administered by [Alex
+ Olivas](mailto:olivas@icecube.umd.edu). Feel free to send an email if you'd like more
+ information about the program.
+
+
+
+
+
+Revised 14 September 2015
+
+
+
+

community/policy.html

@@ -0,0 +1,415 @@
+---
+title: Boost Discussion Policy
+copyright: Beman Dawes, Rob Stewart, David Abrahams, 2000-2005.
+revised: 
+---
+
+
+Boost Discussion Policy
+
+
+
+Boost Discussion Policy
+=======================
+
+Email discussion is the tie that binds boost members
+ together into a community. If the discussion is stimulating and
+ effective, the community thrives. If the discussion degenerates
+ into name-calling and ill will, the community withers and
+ dies.
+
+
+* [Acceptable Topics](#acceptable)
+* [Unacceptable Topics](#unacceptable)
+* [Effective Posting](#effective)
+	+ [Well-Crafted Posting is Worth the Effort](#well-crafted)
+	+ [Put the Library Name in the Subject Line](#subject-line)
+	+ [Don't Use Tabs](#tabs)
+	+ [Limit Line
+	 Length](#longlines)
+	+ [Don't Overquote, Don't Top-Post, and Do 
+	 Use Inline Replies for Readable Quotations](#quoting)
+	+ [Keep the Formatting of Quotations Consistent](#formatting-quotations)
+	+ [Summarizing and Referring to Earlier Messages](#summarizing-referring)
+	+ [Maintain the Integrity of Discussion Threads](#discussion-threads)
+	+ [Keep The Size of Your Posting Manageable](#max-size)
+* [Prohibited Behavior](#behavior)
+	+ [Flame wars](#flame-wars)
+	+ [Third-party attacks](#third-party-attacks)
+	+ [Off-topic posts](#off-topic-posts)
+* [Culture](#culture)
+* [Guidelines for Effective Discussions](#effective-discussions)
+* [Library Names](#lib_names)
+
+
+Acceptable
+ topics
+------------------
+
+
+* Queries to determine interest in a possible library
+ submission.
+* Technical discussions about a proposed or existing
+ library, including bug reports and requests for help.
+* Formal Reviews of proposed libraries.
+* Reports of user experiences with Boost libraries.
+* Boost administration or policies.
+* Compiler specific workarounds as applied to Boost
+ libraries.
+
+
+Other topics related to boost development may be acceptable,
+ at the discretion of moderators. If unsure, go ahead and post.
+ The moderators will let you know.
+
+
+Unacceptable
+ Topics
+--------------------
+
+
+* Advertisements for commercial products.
+* Requests for help getting non-boost code to compile with
+ your compiler. Try the comp.lang.c++.moderated newsgroup
+ instead.
+* Requests for help interpreting the C++ standard. Try the
+ comp.std.c++ newsgroup instead.
+* Job offers.
+* Requests for solutions to homework assignments.
+
+
+Effective
+ Posting
+------------------
+
+
+Most Boost mailing lists host a great deal of traffic, so
+ your post is usually competing for attention with many other
+ communications. This section describes how to make sure it has
+ the desired impact.
+
+
+### Well-Crafted Posting is Worth the Effort
+
+
+Don't forget, you're a single writer but there are many
+ readers, and you want them to stay interested in what you're
+ saying. Saving your readers a little time and effort is usually
+ worth the extra time you spend when writing a message. Also,
+ boost discussions are saved for posterity, as rationales and
+ history of the work we do. A post's usefulness in the future is
+ determined by its readability.
+
+
+### Put the Library Name in the Subject Line
+
+
+When your post is related to a particular Boost library,
+ it's helpful to put the library name in square brackets at the
+ beginning of the subject line, e.g.
+> 
+> Subject: [Regex] Why doesn't this pattern match?
+> 
+> 
+> 
+
+
+The Boost developers' list is a high-volume mailing list,
+ and most maintainers don't have time to read every message. A
+ tag on the subject line will help ensure the right people see
+ your post.
+
+
+### Don't Use Tabs
+
+
+If you use tabs to indent your source code, convert them to
+ spaces before inserting the code in a posting. Something in the
+ processing chain usually strips all the indentation and leaves
+ a mess behind.
+
+
+### Limit Line
+ Length
+
+
+If you put source code in your postings and your mailer
+ wraps long lines automatically, either keep the code narrow or
+ insert the code as an (inline, if possible) attachment. That
+ will help ensure others can read what you've posted.
+
+
+### Don't Overquote, Don't 
+ Top-Post, and Do Use Inline Replies for Readable Quotations
+
+
+Please **prune extraneous quoted text** from
+ replies so that only the relevant parts are included. It will
+ save time and make your post more valuable when readers do not
+ have to find out which exact part of a previous message you
+ are responding to.
+
+
+Don't [top-post](http://en.wikipedia.org/wiki/Posting_style#Top-posting);
+ inline replies are the appropriate [posting style](http://en.wikipedia.org/wiki/Posting_style)
+ for Boost lists.
+
+
+The common and very useful inline approach cites the small
+ fractions of the message you are actually responding to and
+ puts your response directly beneath each citation, with a blank
+ line separating them for readability:
+```
+Person-you're-replying-to wrote:
+
+> Some part of a paragraph that you wish to reply to goes 
+> here; there may be several lines.
+
+Your response to that part of the message goes here.  There may,
+of course, be several lines.
+
+> The second part of the  paragraph that is relevant to your 
+> reply goes here; again there may be several lines.
+
+Your response to the second part of the message goes here.
+...
+
+```
+
+For more information about effective use of quotation in
+ posts, see [this helpful guide](http://www.netmeister.org/news/learn2quote.html).
+
+
+### Keep the Formatting of Quotations Consistent
+
+
+Some email and news clients use poor word wrapping
+ algorithms that leave successive lines from the same quotation
+ with differing numbers of leading "`>`"
+ characters. **Microsoft Outlook** and
+ **Outlook Express**, and some web clients, are
+ especially bad about this. If your client offends in this way,
+ please take the effort to clean up the mess it makes in quoted
+ text. Remember, even if you didn't write the original text,
+ it's *your* posting; whether you get your point across
+ depends on its readability.
+
+
+The Microsoft clients also create an unusually verbose
+ header at the beginning of the original message text and leave
+ the cursor at the beginning of the message, which encourages
+ users to write their replies before all of the quoted text
+ rather than putting the reply in context. Fortunately, Dominic
+ Jain has written a utility that fixes all of these problems
+ automatically: [Outlook Quotefix](http://home.in.tum.de/~jain/software/outlook-quotefix/) for Outlook Users and [OE QuoteFix](http://home.in.tum.de/~jain/software/oe-quotefix/) for users of Outlook Express.
+
+
+### Summarizing and Referring to Earlier Messages
+
+
+A summary of the foregoing thread is only needed after a
+ long discussion, especially when the topic is drifting or a
+ result has been achieved in a discussion. The mail system will
+ do the tracking that is needed to enable mail readers to
+ display message threads (and every decent mail reader supports
+ that).
+
+
+If you ever have to refer to single message earlier in a
+ thread or in a different thread then you can use a URL to the
+ [message archives](groups.html#archive). To help to
+ keep those URLs short, you can use [tinyurl.com](http://tinyurl.com). Citing the relevant portion
+ of a message you link to is often helpful (if the citation is
+ small).
+
+
+### Maintain the Integrity of Discussion Threads
+
+
+**When starting a new topic, always send a fresh
+ message**, rather than beginning a reply to some other
+ message and replacing the subject and body. Many mailers can detect the thread you started with and will show the
+ new message as part of the original thread, which probably
+ isn't what you intended. Follow this guideline for your own
+ sake as well as for others'. Often, people scanning for
+ relevant messages will decide they're done with a topic and
+ hide or kill the entire thread: your message will be missed,
+ and you won't get the response you're looking for.
+
+
+By the same token, **When replying to an existing
+ message, use your mailer's "Reply" function**, so that
+ the reply shows up as part of the same discussion thread.
+
+
+**Do not reply to digests** if you are a digest
+ delivery subscriber. Your reply will not be properly threaded
+ and will probably have the wrong subject line. Instead, you can
+ reply through the [GMane web interface](http://news.gmane.org/gmane.comp.lib.boost.devel).
+
+
+### Keep The Size of Your Posting Manageable
+
+
+The mailing list software automatically limits message and 
+ attachment size to a reasonable amount, typically 75K, which is 
+ adjusted from time-to-time by the moderators. This limit is a 
+ courtesy to those who rely on dial-up Internet access and let's 
+ face it, no one wants to read a posting that consists of 75K of 
+ error message text.
+
+
+Prohibited
+ Behavior
+--------------------
+
+
+Prohibited behavior will not be tolerated. The moderators
+ will ban postings by abusers.
+
+
+### Flame wars
+
+
+Personal insults, argument for the sake of argument, and all
+ the other behaviors which fall into the "flame war" category
+ are prohibited. Discussions should focus on technical
+ arguments, not the personality traits or motives of
+ participants.
+
+
+### Third-party attacks
+
+
+Attacks on third parties such as software vendors, hardware
+ vendors, or any other organizations, are prohibited. Boost
+ exists to unite and serve the entire C++ community, not to
+ disparage the work of others.
+
+
+Does this mean that we ban the occasional complaint or wry
+ remark about a troublesome compiler? No, but be wary of
+ overdoing it.
+
+
+### Off-topic posts
+
+
+Discussions that stray from the acceptable topics are
+ strongly discouraged. While off-topic posts are often well
+ meaning and not as individually corrosive as other abuses,
+ cumulatively the distraction damages the effectiveness of
+ discussion.
+
+
+Culture
+-------
+
+
+In addition to technical skills, Boost members value
+ collaboration, acknowledgment of the help of others, and a
+ certain level of politeness. Boost membership is very
+ international, and ranges widely in age and other
+ characteristics. Think of discussion as occurring among
+ colleagues in a widely read forum, rather than among a few
+ close friends.
+
+
+Always remember that the cumulative effort spent by people
+ reading your contribution scales with the (already large)
+ number of boost members. Thus, do invest time and effort to
+ make your message as readable as possible. Adhere to English
+ syntax and grammar rules such as proper capitalization. Avoid
+ copious informalism, colloquial language, or abbreviations,
+ they may not be understood by all readers. Re-read your message
+ before submitting it.
+
+
+Guidelines for Effective Discussions
+------------------------------------
+
+
+Apply social engineering to prevent heated technical
+ discussion from degenerating into a shouting match, and to
+ actively encourage the cooperation upon which Boost
+ depends.
+
+
+* Questions help. If someone suggests something that you
+ don't think will work, then replying with a question like
+ "will that compile?" or "won't that fail to compile, or am I
+ missing something?" is a lot smoother than "That's 
+ stupid - it won't compile." Saying "that fails to compile for
+ me, and seems to violate section n.n.n of the standard" would
+ be yet another way to be firm without being abrasive.
+* If most of the discussion has been code-free
+ generalities, posting a bit of sample code can focus people
+ on the practical issues.
+* If most of the discussion has been in terms of specific
+ code, try to talk a bit about hidden assumptions and
+ generalities that may be preventing discussion closure.
+* Taking a time-out is often effective. Just say: "Let me
+ think about that for a day or two. Let's take a time-out to
+ digest the discussion so far."
+
+
+Avoid ***Parkinson's Bicycle Shed***.
+ Parkinson described a committee formed to oversee design of an
+ early nuclear power plant. There were three agenda items - when
+ to have tea, where to put the bicycle shed, and how to ensure
+ nuclear safety. Tea was disposed of quickly as trivial. Nuclear
+ safety was discussed for only an hour - it was so complex,
+ scary, and technical that even among experts few felt
+ comfortable with the issues. Endless days were then spent
+ discussing construction of the bicycle shed (the parking lot
+ would be the modern equivalent) because everyone thought they
+ understood the issues and felt comfortable discussing them.
+
+
+Library Names
+-------------
+
+
+In order to ensure a uniform presentation in books and
+ articles, we have adopted a convention for referring to Boost
+ libraries. Library names can either be written in a compact
+ form with a dot, as "Boost.Name", or in a long form
+ as "the Boost Name library." For example:
+> 
+> **Boost.Python** serves a very different
+>  purpose from **the Boost Graph library**.
+> 
+> 
+> 
+
+
+Note that the word "library" is not part of the name, and as
+ such isn't capitalized.
+
+
+Please take care to avoid confusion in discussions between
+ libraries that have been accepted into Boost and those that
+ have not. Acceptance as a Boost library indicates that the code
+ and design have passed through our peer-review process; failing
+ to make the distinction devalues the hard work of library
+ authors who've gone through that process. Here are some
+ suggested ways to describe potential Boost libraries:
+
+
+* the proposed Boost Name library
+* the Boost.Name candidate
+* the Name library (probably the best choice
+ where applicable)
+
+
+Note that this policy only applies to discussions, not to
+ the documentation, directory structure, or even identifiers in
+ the code of potential Boost libraries.
+
+
+
+
+
+
+
+

community/requests.html

@@ -0,0 +1,43 @@
+---
+title: Requesting New Features
+copyright: 
+revised: 
+---
+
+
+Requesting New Features
+
+
+
+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](/community/groups.html#users) or
+ [boost mailing list](/community/groups.html#main)
+ (if you are posting for the first time, please read our
+ [discussion
+ policy](https://www.boost.org/more/discussion_policy.htm) before you actually post).
+
+
+You can also try submitting a feature request to our
+ [issue tracker](https://github.com/boostorg/)
+ on GitHub, 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](/development/requirements.html#Acknowledgements)
+ section!
+
+
+
+
+
+
+© html) 2002
+
+

community/review_schedule.html

@@ -0,0 +1,456 @@
+---
+title: Boost Formal Review Schedule
+copyright: Beman Dawes, Tom Brinkman, Jeff Garland, 2001-2005.
+revised: 
+---
+
+
+Boost Formal Review Schedule
+
+
+
+Boost Formal Review Schedule
+============================
+
+Reviews are scheduled when the review wizards approve a
+ review manager and agree with the manager and author on dates.
+ See [Formal Review Process](reviews.html) for more
+ information.
+
+
+In addition to upcoming reviews, the schedule includes
+ recent reviews already completed; that helps track review
+ manager assignments and libraries reviewed but not yet posted
+ on the website. There is often a lag between acceptance and
+ site posting as authors address issues raised in the formal
+ review.
+
+
+Schedule
+--------
+
+| Submission | Submitter | Link | Review Manager | Review Dates |
+| --- | --- | --- | --- | --- |
+| URL | Vinnie Falco, Alan de Freitas | * [Github](https://github.com/CPPAlliance/url)
+* [Documentation](https://master.url.cpp.al/)
+ | [Klemens Morgenstern](https://lists.boost.org/Archives/boost/2022/06/253225.php) | August 13, 2022 - August 22, 2022 |
+| Text (mini-review) | Zach Laine | * [Github](https://github.com/tzlaine/text)
+* [Documentation](https://tzlaine.github.io/text)
+ | [Needed!](https://lists.boost.org/Archives/boost/2020/08/249594.php) | - |
+
+
+Past Review Results and Milestones
+----------------------------------
+
+| Submission | Submitter | Review Manager | Review Dates | Result |
+| --- | --- | --- | --- | --- |
+| MySQL | Ruben Perez | Richard Hodges | May 9, 2022 - May 18, 2022 | ~~[Pending](https://lists.boost.org/Archives/boost/2022/05/252898.php)~~
+[Accepted](https://lists.boost.org/Archives/boost//2022/06/253193.php) || Lambda2 | Peter Dimov | Joel de Guzman | March 22, 2021 - March 31, 2021 | ~~[Pending](https://lists.boost.org/Archives/boost/2021/03/251218.php)~~
+[Accepted](https://lists.boost.org/Archives/boost/2021/04/251393.php) || Describe | Peter Dimov | Richard Hodges | March 1, 2021 - March 10, 2021 | ~~[Pending](https://lists.boost.org/Archives/boost/2021/02/250933.php)~~
+[Accepted](https://lists.boost.org/Archives/boost/2021/03/251099.php) |
+| PFR(Precise and Flat Reflection) | Antony Polukhin | Benedek Thaler | September 28, 2020 - October 7, 2020 | ~~[Pending](https://lists.boost.org/Archives/boost/2020/09/250077.php)~~
+[Accepted](https://lists.boost.org/Archives/boost/2020/10/250176.php) |
+| JSON | Vinnie Falco, Krystian Stasiowski | Pranam Lashkari | September 14, 2020 - September 23, 2020 | ~~[Pending](https://lists.boost.org/Archives/boost/2020/09/249708.php)~~
+[Accepted](https://lists.boost.org/Archives/boost/2020/10/250129.php) |
+| LEAF(Lightweight Error Augmentation Framework) | Emil Dotchevski | Michael Caisse | May 22, 2020 - May 31, 2020 | ~~[Pending](https://lists.boost.org/Archives/boost/2020/05/248850.php)~~
+[Accepted](https://lists.boost.org/Archives/boost/2020/08/249657.php) |
+| Text | Zach Laine | Glen Fernandes | June 11, 2020 - June 20, 2020 | ~~[Pending](https://lists.boost.org/Archives/boost/2020/06/249094.php)~~
+[Rejected](https://lists.boost.org/Archives/boost/2020/06/249242.php) |
+| Review Wizard Status Report |  | Mateusz Loskot | May 20, 2020 | [Report](https://lists.boost.org/Archives/boost/2020/05/248944.php) |
+| Boost 1.73.0 Released |  | Marshall Clow | April 28, 2020 | [Notes](https://www.boost.org/users/history/version_1_73_0.html) |
+| Boost 1.72.0 Released |  | Marshall Clow | December 11, 2019 | [Notes](https://www.boost.org/users/history/version_1_72_0.html) |
+| STLInterfaces | Zach Laine | Barrett Adair | December 10, 2019 - December 19, 2019 | ~~[Pending](https://lists.boost.org/boost-announce/2019/12/0564.php)~~
+[Conditionally Accepted](https://lists.boost.org/boost-announce/2019/12/0568.php) |
+| StaticString (was FixedString) | Krystian Stasiowski and Vinnie Falco | Joaquin M López Muñoz | November 25, 2019 - December 4, 2019 | ~~[Pending](https://lists.boost.org/boost-announce/2019/11/0563.php)~~
+[Accepted -- Added in 1.73](https://lists.boost.org/Archives/boost/2020/02/248229.php) |
+| Boost 1.71.0 Released |  | Marshall Clow | August 19, 2019 | [Notes](https://www.boost.org/users/history/version_1_71_0.html) |
+| out\_ptr | JeanHeyd Meneide | Zach Laine | June 16, 2019 - July 10, 2019 | ~~[Pending](https://lists.boost.org/boost-announce/2019/06/0556.php)~~
+[Rejected](https://lists.boost.org/boost-announce/2019/07/0558.php) |
+| Boost 1.70.0 Released |  | Marshall Clow | April 12, 2019 | [Notes](https://www.boost.org/users/history/version_1_70_0.html) |
+| Variant2 | Peter Dimov | Michael Caisse | April 1, 2019 - April 15, 2019 | ~~[Ongoing](https://lists.boost.org/Archives/boost/2019/03/245563.php)~~
+[Accepted -- Added in 1.71](https://lists.boost.org/boost-announce/2019/06/0553.php) |
+| Boost 1.69.0 Released |  | Marshall Clow | December 11, 2018 | [Notes](https://www.boost.org/users/history/version_1_69_0.html) |
+| Histogram | Hans Dembinski | Mateusz Loskot | September 17, 2018 - September 26, 2018 | ~~[Pending](https://lists.boost.org/boost-announce/2018/09/0544.php)~~
+[Accepted -- Added in 1.70](https://lists.boost.org/boost-announce/2018/10/0548.php) |
+| Boost 1.68.0 Released |  | Marshall Clow | August 09, 2018 | [Notes](https://www.boost.org/users/history/version_1_68_0.html) |
+| Boost 1.67.0 Released |  | Daniel James | April 16, 2018 | [Notes](https://www.boost.org/users/history/version_1_67_0.html) |
+| YAP | Zach Laine | Louis Dionne | February 5, 2018 - February 14, 2018 | ~~[Ongoing](https://lists.boost.org/boost-announce/2018/02/0537.php)
+[Conditionally Accepted](https://lists.boost.org/boost-announce/2018/03/0540.php)~~
+[Accepted -- Added in 1.70](https://lists.boost.org/boost-announce/2018/06/0542.php) |
+| Outcome | Niall Douglas | Charley Bay | January 19, 2018 - January 28, 2018 | ~~[Pending](https://lists.boost.org/boost-announce/2018/01/0533.php)~~
+[Accepted -- Added in 1.70](https://lists.boost.org/boost-announce/2018/02/0536.php) |
+| Boost 1.66.0 Released |  | Daniel James | December 19, 2017 | [Notes](https://www.boost.org/users/history/version_1_66_0.html) |
+| Double-Ended | Benedek Thaler | Thorsten Ottosen | September 21, 2017 - October 7, 2017 | ~~[Pending](https://lists.boost.org/boost-announce/2017/09/0528.php)~~
+[Conditionally Accepted](https://lists.boost.org/boost-announce/2017/10/0530.php) |
+| Fit (now HOF) | Paul Fultz | Matt Calabrese | September 8, 2017 - September 20, 2017 | ~~[Pending](https://lists.boost.org/boost-announce/2017/09/0526.php)~~
+[Accepted -- Added in 1.67](https://lists.boost.org/boost-announce/2017/09/0529.php) |
+| Boost 1.65.1 Released |  | Daniel James | September 7, 2017 | [Notes](https://www.boost.org/users/history/version_1_65_1.html) |
+| Boost 1.65.0 Released |  | Daniel James | August 21, 2017 | [Notes](https://www.boost.org/users/history/version_1_65_0.html) |
+| mp11 | Peter Dimov | Bjorn Reese | July 15, 2017 - July 24, 2017 | ~~[Ongoing](https://lists.boost.org/boost-announce/2017/07/0519.php)~~
+[Accepted -- Added in 1.66](https://lists.boost.org/boost-announce/2017/08/0520.php) |
+| Beast | Vinnie Falco | Michael Caisse | July 1, 2017 - July 10, 2017 | ~~[Pending](https://lists.boost.org/boost-announce/2017/06/0515.php)~~
+[Accepted -- Added in 1.66](https://lists.boost.org/Archives/boost/2017/07/237385.php) |
+| pdqsort | Orson Peters | Steven Ross | June 21, 2017 - June 30, 2017 | [Accepted](https://lists.boost.org/boost-announce/2017/06/0518.php) |
+| Nowide | Artyom Beilis | Frédéric Bron | June 12, 2017 - June 21, 2017 | ~~[Pending](https://lists.boost.org/boost-announce/2017/06/0512.php)~~
+[Accepted -- Added in 1.73](https://lists.boost.org/boost-announce/2017/06/0516.php) |
+| Timsort | Alexander Zaitsev | Steven Ross | June 3, 2017 - June 12, 2017 | ~~[Ongoing](https://lists.boost.org/boost-announce/2017/06/0509.php)~~
+[Rejected](https://lists.boost.org/boost-announce/2017/06/0513.php) |
+| Outcome | Niall Douglas | Charley Bay | May 19, 2017 - May 28, 2017 | ~~[Pending](https://lists.boost.org/boost-announce/2017/05/0504.php)~~
+[Rejected](https://lists.boost.org/boost-announce/2017/06/0510.php) |
+| PolyCollection | Joaquín Mª López Muñoz | Ion Gaztañaga | May 3, 2017 - May 12, 2017 | ~~[Ongoing](https://lists.boost.org/boost-announce/2017/05/0502.php)~~
+[Accepted -- Added in 1.65](https://lists.boost.org/boost-announce/2017/05/0505.php) |
+| Boost 1.64.0 Released |  | Rene Rivera | April 19, 2017 | [Notes](https://www.boost.org/users/history/version_1_64_0.html) |
+| CallableTraits | Barrett Adair | Louis Dionne | April 3, 2017 - April 12, 2017 | ~~[Ongoing](https://lists.boost.org/Archives/boost/2017/03/234005.php)~~
+[Conditionally Accepted -- Added in 1.66](https://lists.boost.org/Archives/boost/2017/04/234513.php) |
+| Stacktrace | Antony Polukhin | Niall Douglas | March 17, 2017 - March 26, 2017 | ~~[Ongoing](https://lists.boost.org/boost-announce/2017/03/0493.php)~~
+[Accepted -- Added in 1.65](https://lists.boost.org/boost-announce/2017/03/0496.php) |
+| Safe Numerics | Robert Ramey | Andrzej Krzemienski | March 2, 2017 - March 16, 2017 | ~~[Ongoing](https://lists.boost.org/boost-announce/2017/03/0491.php)~~
+[Conditionally Accepted -- Added in 1.69](https://lists.boost.org/boost-announce/2017/03/0494.php) |
+| Boost 1.63.0 Released |  | Marshall Clow | December 26, 2016 | [Notes](https://www.boost.org/users/history/version_1_63_0.html) |
+| Stacktrace | Antony Polukhin | Niall Douglas | December 14, 2016 - December 23, 2016 | ~~[Pending](https://lists.boost.org/boost-announce/2016/12/0483.php)~~
+[Conditionally Accepted](https://lists.boost.org/boost-announce/2017/01/0486.php) |
+| Synapse | Emil Dotchevski | Edward Diener | December 2, 2016 - December 11, 2016 | ~~[Pending](https://lists.boost.org/boost-announce/2016/12/0479.php)~~
+[Rejected](https://lists.boost.org/boost-announce/2016/12/0484.php) |
+| Parallel Sorting Sub-library | Francisco José Tapia | Steven Ross | November 11, 2016 - November 20, 2016 | ~~[Pending](https://lists.boost.org/Archives/boost/2016/11/231544.php)~~ 
+[Accepted](https://lists.boost.org/Archives/boost/2016/11/231732.php)  |
+| Process | Klemens Morgenstern | Antony Polukhin | October 27, 2016 - November 5, 2016 | ~~[Pending](https://lists.boost.org/boost-announce/2016/10/0476.php)~~ 
+[Accepted -- Added in 1.64](https://lists.boost.org/boost-announce/2016/11/0477.php)  |
+| Boost 1.62.0 Released |  | Rene Rivera | September 28, 2016 | [Notes](https://www.boost.org/users/history/version_1_62_0.html) |
+| Fiber (mini-review) | Oliver Kowalke | Nat Goodspeed | May 23, 2016 - June 2, 2016 | ~~[Pending](https://lists.boost.org/boost-announce/2016/05/0473.php)~~
+[Accepted -- Added in 1.62](https://lists.boost.org/boost-announce/2016/06/0474.php) |
+| Review Wizard Status Report |  | Ronald Garcia | May 19, 2016 | [Report](https://lists.boost.org/boost-announce/2016/05/0471.php) |
+| Boost 1.61.0 Released |  | Rene Rivera | May 13, 2016 | [Notes](https://www.boost.org/users/history/version_1_61_0.html) |
+| Fit | Paul Fultz | Vicente Botet | March 2, 2016 - March 13, 2016 | ~~[Ongoing](https://lists.boost.org/Archives/boost/2016/03/228107.php)~~
+[Rejected](https://lists.boost.org/Archives/boost/2016/04/228770.php) |
+| Quaternions, Vectors, Matrices (QVM) | Emil Dotchevski | Adam Wulkiewicz | December 7, 2015 - December 23, 2015 | ~~[Ongoing](https://lists.boost.org/boost-announce/2015/12/0458.php)~~
+[Accepted -- Added in 1.62](https://lists.boost.org/Archives/boost/2016/01/227027.php) |
+| Boost 1.60.0 Released |  | Marshall Clow | December 17, 2015 | [Notes](https://www.boost.org/users/news/version_1_60_0) |
+| Fiber (mini-review) | Oliver Kowalke | Nat Goodspeed | September 4, 2015 - September 13, 2015 | ~~[Pending](https://lists.boost.org/boost-announce/2015/09/0453.php)~~
+[Continuing Conditionally Accepted](https://lists.boost.org/boost-announce/2015/10/0456.php) |
+| Asynchronous File I/O | Niall Douglas and
+ Paul Kirth | Ahmed Charles | August 21, 2015 - August 31, 2015 | ~~[Pending](https://lists.boost.org/boost-announce/2015/08/0451.php)~~
+ Rejected (no result posted)
+  |
+| Boost 1.59.0 Released |  | Marshall Clow | August 13, 2015 | [Notes](https://www.boost.org/users/news/version_1_59_0) |
+| Http | Vinícius dos Santos Oliveira | Bjorn Reese | August 7, 2015 - August 16, 2015 | ~~[Pending](https://lists.boost.org/boost-announce/2015/08/0449.php)~~
+[Rejected](https://lists.boost.org/boost-announce/2015/08/0452.php) |
+| DLL | Antony Polukhin | Vladimir Prus | June 29, 2015 - July 12, 2015 | ~~[Pending](https://lists.boost.org/Archives/boost/2015/07/223995.php)~~
+[Accepted -- Added in 1.61](https://lists.boost.org/boost-announce/2015/07/0448.php) |
+| Hana | Louis Dionne | Glen Fernandes | June 10, 2015 - June 24, 2015 | [Accepted -- Added in 1.61](https://lists.boost.org/boost-announce/2015/07/0443.php) |
+| Metaparse | Abel Sinkovics | Christophe Henry | May 25, 2015 - June 7, 2015 | ~~[Pending](https://lists.boost.org/Archives/boost/2015/05/222478.php)~~
+[Accepted -- Added in 1.61](https://lists.boost.org/boost-announce/2015/07/0446.php) |
+| Boost 1.58.0 Released |  | Marshall Clow | April 17, 2015 | [Notes](https://www.boost.org/users/news/version_1_58_0) |
+| Endian Mini-Review | Beman Dawes | Joel Falcou | January 23, 2015 - February 1, 2015 | ~~[Ongoing](https://lists.boost.org/boost-announce/2015/01/0428.php)~~
+[Accepted -- Added in 1.58](https://lists.boost.org/Archives/boost/2015/02/220090.php) |
+| Review Wizard Status Report |  | Ronald Garcia | January 22, 2015 | [Report](https://lists.boost.org/boost-announce/2015/01/0427.php) |
+| Compute | Kyle Lutz | Antony Polukhin | December 15, 2014 - December 30, 2014 | ~~[Ongoing](https://lists.boost.org/boost-announce/2014/12/0423.php)~~ [Accepted -- Added in 1.61](https://lists.boost.org/boost-announce/2015/01/0425.php) |
+| Sort | Steven Ross | Edward Diener | November 10, 2014 - November 19, 2014 | ~~[Pending](https://lists.boost.org/boost-announce/2014/11/0421.php)~~ [Accepted
+ -- Added in 1.58](https://lists.boost.org/boost-announce/2014/11/0422.php) |
+| Boost 1.57.0 Released |  | Marshall Clow | November 3, 2014 | [Notes](https://www.boost.org/users/news/version_1_57_0) |
+| Review Wizard Status Report |  | Ronald Garcia | August 30, 2014 | [Report](https://lists.boost.org/boost-announce/2014/08/0414.php) |
+| Variadic Macro Data | Edward Diener | Steven Watanabe | August 21, 2014 - August 30, 2014 | ~~[Pending](https://lists.boost.org/boost-announce/2014/08/0413.php)~~
+[Accepted -- Added in 1.60](https://lists.boost.org/boost-announce/2015/02/0432.php) |
+| Boost 1.56.0 Released |  | Marshall Clow | August 7, 2014 | [Notes](https://www.boost.org/users/news/version_1_56_0) |
+| Convert | Vladimir Batov | Edward Diener | May 12, 2014 - May 25, 2014 | ~~[Pending](https://lists.boost.org/boost-announce/2014/05/0403.php)~~
+[Accepted](https://lists.boost.org/boost-announce/2014/06/0406.php) |
+| TypeIndex Mini-Review | Antony Polukhin | Niall Douglas | April 21, 2014 - April 30, 2014 | ~~[Pending](https://lists.boost.org/boost-announce/2014/04/0399.php)~~
+[Accepted
+ -- Added in 1.56](https://lists.boost.org/boost-announce/2014/05/0402.php) |
+| Align | Glen Fernandes | Ahmed Charles | April 11, 2014 - April 20, 2014 | ~~[Pending](https://lists.boost.org/boost-announce/2014/04/0398.php)~~
+[Accepted
+ -- Added in 1.56](https://lists.boost.org/boost-announce/2014/04/0400.php) |
+| Fiber | Oliver Kowalke | Nat Goodspeed | January 6, 2014 - January 15, 2014 | ~~[Pending](https://lists.boost.org/boost-announce/2014/01/0392.php)~~
+[Conditionally
+ Accepted](https://lists.boost.org/boost-announce/2014/01/0393.php) |
+| TypeIndex | Antony Polukhin | Niall Douglas | November 11, 2013 - November 20, 2013 | ~~[Conditionally
+ Accepted](https://lists.boost.org/boost-announce/2013/11/0389.php)~~ |
+| Boost 1.55.0 Released |  | Marshall Clow | November 11, 2013 | [Notes](https://www.boost.org/users/news/version_1_55_0) |
+| Boost 1.54.0 Released |  | Marshall Clow | July 1, 2013 | [Notes](https://www.boost.org/users/news/version_1_54_0) |
+| Review Wizard Status Report |  | Ronald Garcia | March 14, 2013 | [Report](https://lists.boost.org/boost-announce/2013/03/0378.php) |
+| Boost 1.53.0 Released |  | Marshall Clow | February 4, 2013 | [Notes](https://www.boost.org/users/news/version_1_53_0) |
+| Review Wizard Status Report |  | Ronald Garcia | November 10, 2012 | [Report](https://lists.boost.org/boost-announce/2012/11/0374.php) |
+| Boost 1.52.0 Released |  | Marshall Clow | October 5, 2012 | [Notes](https://www.boost.org/users/news/version_1_52_0) |
+| Review Wizard Status Report |  | Ronald Garcia | September 27, 2012 | [Report](https://lists.boost.org/boost-announce/2012/09/0370.php) |
+| ODEint | Karsten Ahnert and 
+ Mario Mulansky | Steven Watanabe | September 19, 2012 - September 28, 2012 | ~~[Pending](https://lists.boost.org/boost-announce/2012/09/0369.php)~~
+[Accepted
+ -- Added in 1.53](https://lists.boost.org/boost-announce/2012/10/0371.php) |
+| Coroutine | Oliver Kowalke | Hartmut Kaiser | September 3, 2012 - September 12, 2012 | ~~[Pending](https://lists.boost.org/boost-announce/2012/09/0366.php)~~
+[Accepted
+ -- Added in 1.53](https://lists.boost.org/boost-announce/2012/11/0375.php) |
+| Contract | Lorenzo Caminiti | Dave Abrahams | August 22, 2012 - August 31, 2012 | ~~[Pending](https://lists.boost.org/boost-announce/2012/08/0362.php)~~
+[Accepted -- Added in 1.67](https://lists.boost.org/boost-announce/2012/09/0368.php) |
+| Boost 1.51.0 Released |  | Marshall Clow | August 20, 2012 | [Notes](https://www.boost.org/users/news/version_1_51_0) |
+| Review Wizard Status Report |  | Ronald Garcia | August 15, 2012 | [Report](https://lists.boost.org/boost-announce/2012/08/0360.php) |
+| Type Erasure | Steven Watanabe | Lorenzo Caminiti | July 18, 2012 - July 27, 2012 | ~~[Pending](https://lists.boost.org/boost-announce/2012/07/0357.php)~~
+[Accepted
+ -- Added in 1.54](https://lists.boost.org/boost-announce/2012/08/0364.php) |
+| Review Wizard Status Report |  | Ronald Garcia | July 13, 2012 | [Report](https://lists.boost.org/boost-announce/2012/07/0355.php) |
+| Boost 1.50.0 Released |  | Beman Dawes | June 28, 2012 | [Notes](https://www.boost.org/users/news/version_1_50_0) |
+| Multiprecision Arithmetic | John Maddock | Jeffrey Hellrung | June 8, 2012 - June 17, 2012 | ~~[Pending](https://lists.boost.org/boost-announce/2012/06/0353.php)~~
+[Accepted
+ -- Added in 1.53](https://lists.boost.org/boost-announce/2012/08/0359.php) |
+| Boost 1.49.0 Released |  | Beman Dawes | February 24, 2012 | [Notes](https://www.boost.org/users/news/version_1_49_0) |
+| Predef | Rene Rivera | Joel Falcou | February 20, 2012 - February 29, 2012 | ~~[Pending](https://lists.boost.org/boost-announce/2012/02/0349.php)~~
+[Accepted
+ -- Added in 1.55](https://lists.boost.org/boost-announce/2013/04/0379.php) |
+| Review Wizard Status Report |  | Ronald Garcia | January 10, 2012 | [Report](https://lists.boost.org/boost-announce/2012/01/0344.php) |
+| Context (mini-review) | Oliver Kowalke | Giovanni Deretta | January 2, 2012 - January 11, 2012 | ~~[Pending](https://lists.boost.org/boost-announce/2012/01/0343.php)~~
+[Accepted
+ -- Added in 1.51.0](https://lists.boost.org/boost-announce/2012/01/0348.php) |
+| Boost 1.48.0 Released |  | Beman Dawes | November 16, 2011 | [Notes](https://www.boost.org/users/news/version_1_48_0) |
+| Local | Lorenzo Caminiti | Jeffrey Hellrung | November 10, 2011 - November 19, 2011 | ~~[Pending](https://lists.boost.org/boost-announce/2011/11/0338.php)~~
+[Accepted
+ -- Added in 1.50](https://lists.boost.org/boost-announce/2011/12/0340.php) |
+| Atomic | Helge Bahmann | Tim Blechmann | October 17, 2011 - October 26, 2011 | [Accepted
+ -- Added in 1.53](https://lists.boost.org/boost-announce/2011/11/0337.php) |
+| Algorithm | Marshall Clow | Dave Abrahams | September 22, 2011 - October 1, 2011 | ~~[Pending](https://lists.boost.org/boost-announce/2011/09/0333.php)~~
+[Accepted
+ -- Added in 1.50](https://lists.boost.org/boost-announce/2011/12/0341.php) |
+| Endian | Beman Dawes | Joel Falcou | September 5, 2011 - September 14, 2011 | [Conditionally
+ Accepted](https://lists.boost.org/boost-announce/2011/11/0336.php) |
+| Conversion | Vicente Botet | Gordon Woodhull | August 20, 2011 - August 29, 2011 | ~~[Pending](https://lists.boost.org/boost-announce/2011/08/0330.php)~~
+[Rejected](https://lists.boost.org/boost-announce/2012/07/0356.php) |
+| Containers | Ion Gaztañaga | John Maddock | August 3, 2011 - August 12, 2011 | ~~[Pending](https://lists.boost.org/boost-announce/2011/08/0329.php)~~
+[Accepted -- Added in 1.48.0](https://lists.boost.org/Archives/boost/2011/08/184936.php) |
+| Lockfree | Tim Blechmann | Hartmut Kaiser | July 18, 2011 - July 27, 2011 | [~~Pending~~](https://lists.boost.org/boost-announce/2011/07/0324.php)
+[Accepted
+ -- Added in 1.53](https://lists.boost.org/boost-announce/2011/08/0331.php) |
+| Boost 1.47.0 Released |  | Beman Dawes | July 12, 2011 | [Notes](https://www.boost.org/users/news/version_1_47_0) |
+| Type Traits Introspection | Edward Diener | Joel Falcou | July 1, 2011 - July 10, 2011 | ~~[Pending](https://lists.boost.org/boost-announce/2011/06/0320.php)~~
+~~[Pending](https://lists.boost.org/boost-announce/2011/07/0322.php)~~
+[Accepted
+ -- Added in 1.54](https://lists.boost.org/boost-announce/2011/08/0328.php) |
+| Assign v2 | Erwann Rogard,
+ Thorsten Ottosen | John Bytheway | June 15, 2011 - June 24, 2011 | ~~[Pending](https://lists.boost.org/boost-announce/2011/06/0315.php)~~
+~~[Pending](https://lists.boost.org/boost-announce/2011/06/0319.php)~~
+[Rejected](https://lists.boost.org/boost-announce/2011/07/0321.php) |
+| Heaps | Tim Blechmann | Andrew Sutton | May 30, 2011 - June 8, 2011 | ~~[Pending](https://lists.boost.org/boost-announce/2011/05/0314.php)~~
+[Accepted
+ -- Added in 1.49](https://lists.boost.org/boost-announce/2011/06/0316.php) |
+| Review Wizard Status Report |  | Ronald Garcia | May 23, 2011 | [Report](https://lists.boost.org/boost-announce/2011/05/0311.php) |
+| AutoIndex (Tool) | John Maddock | Daniel James | May 5, 2011 - May 14, 2011 | ~~[Pending](https://lists.boost.org/boost-announce/2011/05/0308.php)~~
+[Accepted
+ -- Added in 1.48.0](https://lists.boost.org/boost-announce/2011/05/0312.php) |
+| Convert | Vladimir Batov | Edward Diener | April 23, 2011 - May 2, 2011- | ~~[Pending](https://lists.boost.org/boost-announce/2011/04/0302.php)~~
+[Withdrawn](https://lists.boost.org/boost-announce/2011/05/0307.php)
+[(Report)](https://lists.boost.org/boost-announce/2011/05/0309.php) |
+| Locale | Artyom Beilis | Chad Nelson | April 7, 2011 - April 16, 2011 | ~~[Pending](https://lists.boost.org/boost-announce/2011/04/0298.php)~~
+~~[Pending](https://lists.boost.org/boost-announce/2011/04/0303.php)~~
+[Accepted
+ -- Added in 1.48.0](https://lists.boost.org/boost-announce/2011/04/0304.php) |
+| Context | Oliver Kowalke | Vicente Botet | March 21, 2011 - March 30, 2011 | ~~[Pending](https://lists.boost.org/boost-announce/2011/03/0296.php)~~
+~~[Accepted
+ Provisionally](https://lists.boost.org/boost-announce/2011/05/0310.php)~~
+[Accepted
+ -- Added in 1.51.0](https://lists.boost.org/boost-announce/2012/01/0348.php) |
+| Type Traits Extensions (Fast-Track) | Frédéric Bron | Joel Falcou | March 14, 2011 - March 18, 2011 | [Accepted
+ -- Added in 1.48.0](https://lists.boost.org/boost-announce/2011/03/0297.php) |
+| Boost 1.46.1 Released |  | Beman Dawes | March 21, 2011 | [Notes](https://www.boost.org/users/news/version_1_46_1) |
+| Review Wizard Status Report |  | Ronald Garcia | March 4, 2011 | [Report](https://lists.boost.org/boost-announce/2011/03/0289.php) |
+| XInt | Chad Nelson | Vladimir Prus | March 2, 2011 - March 12, 2011 | ~~[Pending](https://lists.boost.org/boost-announce/2011/03/0288.php)~~
+[Rejected](https://lists.boost.org/boost-announce/2011/04/0305.php) |
+| Boost 1.46 Released |  | Beman Dawes | February 21, 2011 | [Notes](https://www.boost.org/users/news/version_1_46_0) |
+| Phoenix (mini-review) | Joel de Guzmann | Hartmut Kaiser | February 20, 2011 - March 2, 2011 | [Accepted
+ -- Added in 1.47.0](https://lists.boost.org/boost-announce/2011/03/0291.php) |
+| Process | Boris Schaeling | Marshall Clow | February 7. 2011 - February 16, 2011 | [Rejected](https://lists.boost.org/boost-announce/2011/03/0292.php) |
+| GIL.IO | Christian Henning | Mateusz Loskot | December 1, 2010 - December 10, 2010 | [Accepted
+ -- Added in 1.68.0](https://lists.boost.org/boost-announce/2011/01/0281.php) |
+| Boost 1.45 Released |  | Beman Dawes | November 20, 2010 | [Notes](https://lists.boost.org/boost-announce/2010/11/0272.php) |
+| Chrono | Vicente Botet | Anthony Williams | November 6, 2010 - November 15, 2010 | [Accepted
+ -- Added in 1.47.0](https://lists.boost.org/boost-announce/2011/01/0280.php) |
+| Ratio | Vicente Botet | Anthony Williams | October 2, 2010 - October 11, 2010 | [Accepted
+ -- Added in 1.47.0](https://lists.boost.org/boost-announce/2010/10/0270.php) |
+| Boost 1.44 Released |  | Beman Dawes | August 17, 2010 | [Notes](https://lists.boost.org/boost-announce/2010/08/0264.php) |
+| Boost.Assign Extensions (Mini-Review) | Erwann Rogard | Thorsten Ottosen | June 13, 2010 - June 19, 2010 | [Rejected](https://lists.boost.org/boost-announce/2010/10/0269.php) |
+| Review Wizard Status Report |  | Ronald Garcia | May 26, 2010 | [Report](https://lists.boost.org/boost-announce/2010/05/0262.php) |
+| Move | Ion Gaztañaga | ~~OvermindDL1~~
+ Michael Caisse
+  | May 10, 2010 - May 24, 2010 | [Accepted
+ -- Added in 1.48.0](https://lists.boost.org/boost-announce/2011/02/0283.php) |
+| Boost 1.43 Released |  | Beman Dawes | May 6, 2010 | [Notes](https://lists.boost.org/boost-announce/2010/05/0258.php) |
+| Log | Andrey Semashev | Vladimir Prus | March 8, 2010 - March 17, 2010 | ~~[Accepted
+ Provisionally](https://lists.boost.org/boost-announce/2010/03/0256.php)~~
+ Accepted -- Added in 1.54
+  |
+| Interval Containers | Joachim Faulhaber | Hartmut Kaiser | February 18, 2010 - February 27, 2010 | [Accepted
+ -- Added in 1.46](https://lists.boost.org/boost-announce/2010/04/0257.php) |
+| Boost 1.42 Released |  | Beman Dawes | February 2, 2010 | [Notes](https://lists.boost.org/boost-announce/2010/02/0250.php) |
+| Review Wizard Status Report |  | John Phillips | December 7, 2009 | [Report](../development/report-dec-2009.html) |
+| Meta State Machine (MSM) | Christophe Henry | Dave Abrahams | November 23, 2009 - December 13, 2009 | [Accepted -- Added in 1.44](https://lists.boost.org/Archives/boost/2010/01/160812.php) |
+| Boost 1.41 Released |  | Beman Dawes | November 18, 2009 | [Notes](https://lists.boost.org/boost-announce/2009/11/0241.php) |
+| Geometry | Barend Gehrels,
+ Bruno Lalande,
+ and Mateusz Loskot | Hartmut Kaiser | November 5, 2009 - November 22, 2009 | [Accepted
+ -- Added in 1.47.0](https://lists.boost.org/boost-announce/2009/11/0245.php) |
+| Boost 1.40 Released |  | Beman Dawes | August 27, 2009 | [Notes](https://lists.boost.org/boost-announce/2009/08/0235.php) |
+| Polygon | Lucanus Simonson | Fernando Cacciola | August 24, 2009 - September 2, 2009 | [Accepted
+ -- Added in 1.44](https://lists.boost.org/boost-announce/2009/11/0239.php) |
+| Review Wizard Status Report |  | Ronald Garcia | June 4, 2009 | [Report](../development/report-jun-2009.html) |
+| Boost 1.39 Released |  | Beman Dawes | May 3, 2009 | [Notes](https://lists.boost.org/boost-announce/2009/05/0232.php) |
+| Polynomial | Paweł Kieliszczyk | John Maddock | March 10, 2009 - March 19, 2009 | [Rejected](https://lists.boost.org/boost-announce/2009/04/0228.php) |
+| Boost.Range (Update) | Neil Groves | Thorsten Ottosen | February 20, 2009 - March 3, 2009 | [Accepted
+ -- Added in 1.43](https://lists.boost.org/boost-announce/2009/04/0231.php) |
+| Boost 1.38 Released |  | Beman Dawes | February 9, 2009 | [Notes](https://lists.boost.org/boost-announce/2009/02/0223.php) |
+| Futures (2 candidates) | 1. Braddock Gaskill
+2. Anthony Williams
+ | Tom Brinkman | January 5, 2009 - January 20, 2009 | [Williams
+ Accepted -- Added in 1.41
+ Gaskill Rejected](https://lists.boost.org/boost-announce/2009/04/0229.php) |
+| Constrained Value | Robert Kawulak | ~~Jeff Garland~~
+ Gordon Woodhull
+  | December 1, 2008 - December 10, 2008 | ~~[Accepted](https://lists.boost.org/boost-announce/2010/09/0265.php)~~
+ Orphaned
+  |
+| Review Wizard Status Report |  | John Phillips | November 25, 2008 | [Report](../development/report-nov-2008.html) |
+| Globally Unique Identifier (mini-review) (now
+ UUID) | Andy Tompkins | Hartmut Kaiser | November 23, 2008 - November 29, 2008 | [Accepted
+ -- Added in 1.42](https://lists.boost.org/boost-announce/2009/01/0221.php) |
+| Boost 1.37 Released |  | Beman Dawes | November 3, 2008 | [Notes](https://lists.boost.org/boost-announce/2008/11/0209.php) |
+| Thread-Safe Signals (now Signals2) | Frank Hess | Stjepan Rajko | November 1, 2008 - November 10, 2008 | [Accepted
+ -- Added in 1.39](https://lists.boost.org/boost-announce/2008/11/0211.php) |
+| Phoenix | Joel de Guzman | Hartmut Kaiser | September 21, 2008 - September 30, 2008 | [~~Accepted Conditionally~~](https://lists.boost.org/boost-announce/2008/10/0205.php)
+[~~Under Development~~](https://lists.boost.org/Archives/boost/2010/05/167128.php)
+[Accepted
+ -- Added in 1.47.0](https://lists.boost.org/boost-announce/2011/03/0291.php) |
+| DataFlow Signals | Stjepan Rajko | Jaakko Järvi | September 1, 2008 - September 10, 2008 | [Rejected](https://lists.boost.org/Archives/boost/2008/09/142198.php) |
+| Boost 1.36 Released |  | Beman Dawes | August 14, 2008 | [Notes](https://lists.boost.org/boost-announce/2008/08/0196.php) |
+| Finite State Machines | Andrey Semashev | Martin Vuille | August 11, 2008 - August 27, 2008 | [Rejected](https://lists.boost.org/boost-announce/2008/09/0202.php) ([Notes](https://lists.boost.org/boost-announce/2008/09/0203.php))
+  |
+| Review Wizard Status Report |  | John Phillips | 2008 May 16 | [Report](../development/report-may-2008.html) |
+| Egg | Shunsuke Sogame | Dan Marsden | March 31, 2008 - April 13, 2008 | [Rejected](https://lists.boost.org/boost-announce/2008/05/0192.php) |
+| Boost 1.35 Released |  | Beman Dawes | March 29, 2007 | [Notes](https://lists.boost.org/boost-announce/2008/03/0183.php) |
+| Proto | Eric Niebler | Hartmut Kaiser | March 1, 2008 - March 14, 2008 | [Accepted -- Added in 1.37](https://lists.boost.org/boost-announce/2008/04/0187.php) |
+| Floating Point Utilities | Johan Råde | John Maddock | February 18, 2008 - February 27, 2008 | [Accepted -- Added in 1.??](https://lists.boost.org/boost-announce/2008/03/0179.php) |
+| Logging | John Torjo | Gennadiy Rozental | February 4, 2008 - February 13, 2008 | [Rejected](https://lists.boost.org/boost-announce/2008/03/0181.php) |
+| Flyweight | Joaquín Mª López Muñoz | Ion Gaztañaga | January 21, 2008 - January 30, 2008 | [Accepted -- Added in 1.38](https://lists.boost.org/boost-announce/2008/02/0174.php) |
+| Singleton (fast-track) | Tobias Schwinger | John Torjo | January 14, 2008 - January 18, 2008 | [Rejected](https://lists.boost.org/boost-announce/2008/01/0171.php) |
+| Switch | Steven Watanabe | Stejpan Rajko | January 5, 2008 - January 13, 2008 | ~~[Accepted Provisionally](https://lists.boost.org/boost-announce/2008/01/0166.php)~~ Orphaned
+  |
+| Factory (fast-track) | Tobias Schwinger | John Torjo | December 17, 2007 - December 21, 2007 | [Accepted -- Added in 1.43](https://lists.boost.org/boost-announce/2007/12/0161.php) |
+| Unordered Containers | Daniel James | Ion Gaztañaga | December 7, 2007 - December 16, 2007 | [Accepted -- Added in 1.36](https://lists.boost.org/boost-announce/2007/12/0158.php) |
+| Forward (fast-track) | Tobias Schwinger | John Torjo | December 3, 2007 - December 7, 2007 | [Accepted -- Added in 1.43](https://lists.boost.org/boost-announce/2007/12/0153.php) |
+| Review Wizard Status Report |  | Ronald Garcia | 2007 November 16 | [Report](../development/report-nov-2007.html) |
+| Exception | Emil Dotchevski | Tobias Schwinger | September 27, 2007 - October 7, 2007 | [Accepted
+ -- Added in 1.36](https://lists.boost.org/boost-users/2007/11/31912.php) |
+| Review Wizard Status Report |  | Ronald Garcia | 2007 September 14 | [Report](../development/report-sep-2007.html) |
+| Scope Exit | Alexander Nasonov | ~~Jody Hagins~~
+ John R. Phillips
+  | August 13, 2007 - August 22, 2007- | [Accepted -- Added in 1.38](https://lists.boost.org/boost-announce/2008/05/0190.php) |
+| Time Series | Eric Niebler | John R. Phillips | July 30, 2007 - August 13, 2007 | [~~Accepted~~](https://lists.boost.org/boost-announce/2007/08/0142.php)
+[Orphaned](https://lists.boost.org/Archives/boost/2010/05/167128.php) |
+| Boost 1.34.1 Released |  | Thomas Witt | July 24, 2007 | [Notes](https://lists.boost.org/boost-announce/2007/07/0135.php) |
+| Boost 1.34.0 Released |  | Thomas Witt | May 12, 2007 | [Notes](https://lists.boost.org/boost-announce/2007/05/0131.php) |
+| Globally Unique Identifier | Andy Tompkins | Hartmut Kaiser | April 30, 2007 - May 10, 2007 | ~~[Accepted Provisionally](https://lists.boost.org/boost-announce/2007/05/0134.php)~~
+[Accepted -- Added in 1.42](https://lists.boost.org/boost-announce/2009/01/0221.php) |
+| Math Toolkit | John Maddock | Matthias Schabel | April 11, 2007 - April 27, 2007 | [Accepted -- Added in 1.35](https://lists.boost.org/boost-announce/2007/05/0129.php) |
+| Quantitative Units | Matthias Schabel | John R. Phillips | March 26, 2007 - April 4, 2007 | [Accepted -- Added in 1.36](https://lists.boost.org/boost-announce/2007/04/0126.php) |
+| Intrusive Containers | Ion Gaztañaga | Joaquín Mª López Muñoz | March 12, 2007 - March 21, 2007 | [Accepted -- Added in 1.35](https://lists.boost.org/boost-announce/2007/04/0122.php) |
+| Bimap | Matias Capeletto | Ion Gaztañaga | February 15 2007- March 2, 2007 | [Accepted -- Added in 1.35](https://lists.boost.org/Archives/boost/2007/03/117351.php) |
+| Accumulators | Eric Niebler | John R. Phillips | January 29, 2007 - February 7, 2007 | [Accepted -- Added in 1.36](https://lists.boost.org/boost-announce/2007/02/0114.php) |
+| Function Types (Re-review) | Tobias Schwinger | Tom Brinkman | 2006 November 6 - 2006 November 17 | [Accepted -- Added in 1.35](https://lists.boost.org/boost-announce/2006/11/0106.php) |
+| Generic Image Library | Lubomir Bourdev | Tom Brinkman | 2006 October 5 - 2006 October 25 | [Accepted -- Added in 1.35](https://lists.boost.org/Archives/boost/2006/11/112896.php) |
+| Message Passing | Doug Gregor | Jeremy Siek | 2006 September 6 - 2006 September 15 | [Accepted -- Added in 1.35](https://lists.boost.org/boost-announce/2006/09/0099.php) |
+| Physical Quantities System | Andy Little | Fred Bertsch | 2006 May 31 - 2006 June 9 | [Rejected](https://lists.boost.org/boost-announce/2006/06/0096.php) |
+| Pimpl Pointer | Asger Mangaard | Rene Rivera | 2006 May 15 - 2006 May 24 | [Rejected](https://lists.boost.org/boost-announce/2006/10/0104.php) |
+| Fusion | Joel de Guzman | Ronald Garcia | 2006 May 1 - 2006 May 10 | [Accepted -- Added in 1.35](https://lists.boost.org/boost-announce/2006/06/0094.php) |
+| Property Tree | Marcin Kalicinski | Thorsten Ottosen | 2006 April 18 - 2006 April 30 | [Accepted -- Added in 1.41](https://lists.boost.org/boost-announce/2006/05/0092.php) |
+| Promotion Traits (fast-track) | Alexander Nasonov | Tobias Schwinger | 2006 April 1 - 2006 April 9 | [Accepted -- Added in 1.35](https://lists.boost.org/boost-announce/2006/04/0086.php) |
+| Review Wizard Status Report |  | Tom Brinkman | 2006 March 30 | [Report](../development/report-apr-2006.html) |
+| Shmem (now Interprocess) | Ion Gaztañaga | Fred Bertsch | 2006 February 6 - 2006 February 15 | [Accepted -- Added in 1.35](https://lists.boost.org/boost-announce/2006/02/0083.php) |
+| Fixed Strings | Reece Dunn | Harmut Kaiser | 2006 January 19 - 2006 February 5 | [Rejected](https://lists.boost.org/boost-announce/2006/02/0081.php) |
+| Review Wizard Status Report |  | Ronald Garcia | 2006 January 19 | [Report](../development/report-jan-2006.html) |
+| asio | Christopher Kohlhoff | Jeff Garland | 2005 December 10 -
+ 2005 December 30 | [Accepted -- Added in 1.35](https://lists.boost.org/Archives/boost/2006/03/102287.php) |
+| Boost 1.33.1 Released |  | Doug Gregor | 2005 December 5 | [Notes](https://lists.boost.org/boost-announce/2005/12/0077.php) |
+| Review Wizard Status Report |  | Ronald Garcia | 2005 December 1 | [Report](https://lists.boost.org/boost-announce/2005/12/0076.php) |
+| Logging Library | John Torjo | Hartmut Kaiser | 2005 November 7 - 2005 November 16th | [Rejected](https://lists.boost.org/boost-announce/2005/11/0075.php) |
+| Boost 1.33.1 Beta Released |  | Doug Gregor | 2005 November 9 | [Notes](https://lists.boost.org/boost-announce/2005/11/0073.php) |
+| binary\_int | Scott Schurr and
+ Matt Calabrese | Pavel Vozenilek | 2005 October 13 - 2005 October 20 | [Accepted -- Added in 1.37.](https://lists.boost.org/boost-announce/2006/01/0078.php) |
+| TR1 | John Maddock | Beman Dawes | 2005 September 24 - 2005 October 5 | Accepted -- Added in 1.34 |
+| Xpressive | Eric Niebler | Thomas Witt | 2005 September 8 - 2005 September 18 | Accepted -- Added in 1.34 |
+| Boost 1.33.0 Released |  | Doug Gregor | 17 August 2005 | [Notes](https://lists.boost.org/boost-announce/2005/08/0067.php) |
+| Function Types | Tobias Schwinger | John Maddock | 2005-Jun-6 to 2005-June-16 | ~~[Accepted Provisionally](https://lists.boost.org/boost-announce/2005/06/0066.php)~~,
+ [Accepted -- Added in 1.35](https://lists.boost.org/boost-announce/2006/11/0106.php) |
+| Typeof | Arkadiy Vertleyb and
+ Peder Holt | Andy Little | 2005 May 20 - 2005 May 30 | Accepted -- Added in 1.34 |
+| Singleton | Jason Hise | Pavel Vozenilek | 2005 May 5 - 2005 May 15 | [Rejected](https://lists.boost.org/boost-announce/2005/05/0062.php) |
+| FOREACH Macro | Eric Niebler | Gennadiy Rozental | 2005 April 25 - 2005 May 1 | Accepted -- Added in 1.34 |
+| Hash | Daniel James | Thorsten Ottosen | 2005 Mar 21 - 2005 March 12 | Accepted -- Added in 1.33 |
+| State Chart | Andreas Huber | Pavel Vozenilek | 2005 Feb 23 - 2005 March 9 | Accepted -- Added in 1.34 |
+| Wave | Hartmut Kaiser | Tom Brinkman | 2005 Feb 7 - 2005 Feb 20 | Accepted -- Added in 1.33 |
+| Pointer Containers | Thorsten Ottosen | Pavol Droba | 2004 Sept 26 - Oct 5 | Accepted -- Added in 1.33 |
+| Named Params | David Abrahams &
+ Daniel Wallin | Doug Gregor | 2004 Nov 1 - 2004 Nov 20 | Accepted -- Added in 1.33 |
+| Output Formatters | Reece Dunn | John Torjo | 2004 Sept 11 - Sept 25 | [Rejected](https://lists.boost.org/Archives/boost/2004/10/74535.php) |
+| Iostreams | Jonathan Turkanis | Jeff Garland | 2004 Aug 28 - Sep 11 | Accepted -- Added in 1.33 |
+| More IO | Daryle Walker | Tom Brinkman | 2004 Aug 21 - 28 | Rejected |
+| Tribool | Douglas Gregor | Thomas Witt | 2004 May 19-29 | Accepted -- Added in 1.32 |
+| Assignment | Thorsten Ottosen | Tom Brinkman | 2004 Apr 1 - 11 | Accepted -- Added in 1.32 |
+| Serialization (re-review) | Robert Ramey | Jeff Garland | 2004 Apr 13 - 26 | Accepted -- Added in 1.32 |
+| Container Traits (now Range) | Thorsten Ottosen | Hartmut Kaiser | 2004 Apr 28 - May 7 | Accepted -- Added in 1.32 |
+| Indexed Set (now MultiIndex) | Joaquín Mª López Muñoz | Pavel Vozenilek | 2004 Mar 20 - 30 | [Accepted -- Added in 1.32](https://lists.boost.org/Archives/boost/2004/04/63582.php) |
+| Circular Buffer | Jan Gaspar | Pavel Vozenilek | 2004 Mar 5 - 15 | Accepted -- Added in 1.35 |
+| enable\_if | Jaakko Järvi & 
+ Jeremiah Willcock & 
+ Andrew Lumsdaine | (fasttrack) | Dec 2003 | Accepted -- added in 1.31 |
+| FC++ | Brian McNamara & Yannis Smaragdakis | Mat Marcus | 2004 Feb 14 - Mar 1 | Rejected |
+| Numeric Conversions Library | Fernando Cacciola | Thorsten Ottosen | 8 - 22 Dec 2003 | Accepted -- added in 1.32 |
+| String Algorithm Library | Pavol Droba | Thorsten Ottosen | 17 - 30 Oct 2003 | Accepted -- added in 1.32 |
+| Shifted Pointer | Philippe A. Bouchard | Doug Gregor | 24 - 30 Sep 2003 | Rejected |
+| Fixed-Point Decimal | Bill Seymour | Jens Maurer | 11 - 21 Jul 2003 | Rejected |
+| Math Constants | Paul A. Bristow | Jaap Suter | 06 - 15 Jun 2003 | Rejected |
+| Command Line & Config | Vladimir Prus | Aleksey Gurtovoy | 21 May - 03 Jun 2003 | Accepted -- added in 1.32 |
+| I/O Manipulators and Adaptors | Daryle Walker | Ed Brey | 27 Feb - 11 Mar 2003 | - |
+| Variant | Eric Friedman & Itay Maman | Jeff Garland | 16 - 25 Feb 2003 | Accepted -- added in 1.31 |
+| Optional | Fernando Cacciola | Douglas Gregor | 09 - 18 Dec 2002 | Accepted -- added in 1.30 |
+| Serialization | Robert Ramey | Dave Abrahams | 02 - 11 Nov 2002 | Rejected |
+| Spirit | Joel de Guzman | John Maddock | 11 - 20 Oct 2002 | Accepted -- added in 1.30 |
+| Minmax | Hervé Bronnimann | Thomas Witt | 28 Sep - 07 Oct 2002 | Accepted -- added in 1.32 |
+| Filesystem | Beman Dawes | William Kempf | 14 - 23 Sep 2002 | Accepted -- added in 1.30 |
+| Interval Arithmetic Library | Hervé Bronnimann &
+ Guillaume Melquiond &
+ Sylvain Pion | Beman Dawes | 31 Aug - 09 Sep 2002 | Accepted -- added in 1.30 |
+| Template Meta Programming Library MPL | Aleksey Gurtovoy | Douglas Gregor | 15 - 29 Jul 2002 | Accepted -- added in 1.30 |
+| uBLAS | Joerg Walter & Mathias Koch | Ed Brey | 21 Jun - 01 Jul 2002 | Accepted -- added in 1.29 |
+| Dynamic Bitset | Chuck Alison & Jeremy Siek | Mat Marcus | 08 - 17 Jun 2002 | Accepted -- added in 1.29 |
+| Date / Time | Jeff Garland | Darin Adler | 15 - 24 Apr 2002 | Accepted -- added in 1.29 |
+| Lambda | Jaakko Järvi & Gary Powell | Aleksey Gurtovoy | 08 - 20 Mar 2002 | Accepted and added |
+| Signals | Douglas Gregor | William Kempf | 18 - 27 Feb 2002 | Accepted -- added in 1.29 |
+| I/O State Saver | Daryle Walker | Beman Dawes | 06 - 16 Feb 2002 | Accepted and added |
+| printf-like formatting for iostreams | Samuel Krempp | Jens Maurer | 13 - 23 Jan 2002 | Accepted -- added in 1.29 |
+| Multi-array | Ron Garcia | John Maddock | 02 - 12 Jan 2002 | Accepted -- added in 1.29 |
+| Unit Test Library | Gennadiy Rozental | Jeremy Siek | 01 - 13 Dec 2001 | Accepted and added |
+| GCD Library plus integer additions | Daryle Walker | Dave Abrahams | 17 - 26 Sep 2001 | - |
+| Thread Library | Bill Kempf | Ed Brey | Aug 30 - Sep 8 | Accepted and added |
+| Config System | John Maddock | Doug Gregor | Aug 20 - 29 | Accepted and added |
+| Bind Library | Peter Dimov | Darin Adler | Aug 10 - 19 | Accepted and added |
+| Base from Member Library | Daryle Walker | Beman Dawes | Jul 30 - Aug 9 | - |
+| Coding Guidelines | Dave Abrahams | Aleksey Gurtovoy | Jul 20 - 29 | - |
+| Preprocessor Library | Vesa Karvonen | Jeremy Siek | Jun 28 - Jul 9 | Accepted and added |
+| Tuples Library | Jaakko Järvi | Beman Dawes | Jun 17 - 26 | Accepted and added |
+| Function Library | Doug Gregor | John Maddock | Jun 6 - 16 | Accepted and added |
+| Tokenizer | John Bandela | Doug Gregor | May 28 - Jun 6 | Accepted and added |
+| Special Functions | Hubert Holin | Jens Maurer | May 18 - 27 | Accepted and added |
+
+Review Managers
+---------------
+
+
+In order for a review to proceed, a Boost member must
+ volunteer to manage the review. This should be someone with
+ experience with the review process and knowledge of the
+ library's domain. If you would like to volunteer to become a
+ review manager, please contact Mateusz Loskot
+ (mateusz at loskot dot net) or John Phillips
+ (johnphillipsithaca at gmail dot com).
+
+
+
+
+
+
+
+
+

community/reviews.html

@@ -0,0 +1,373 @@
+---
+title: Boost Formal Review Process
+copyright: Beman Dawes, 2000.
+revised: 
+---
+
+
+Boost Formal Review Process
+
+
+
+Boost Formal Review Process
+===========================
+
+Before Requesting a Formal Review
+---------------------------------
+
+
+**Read and follow the Boost [submission
+ process](/development/submissions.html).** There are several steps a library author
+ must take before a formal review is requested.
+
+* [Introduction](#Introduction)
+* [What to include in Review Comments](#Comments)
+* [Results](#Results)
+* [Notes for Review Managers](#Review_Manager)
+* [Notes for Library Submitters](#Submitters)
+* [Library Maintainer's Rights and
+ Responsibilities](#Maintainer)
+* [Review Wizard](#Wizard)
+* [Fast Track Reviews](#Fast-Track)
+
+
+Introduction
+------------
+
+
+Proposed libraries are accepted into Boost only after
+ undergoing a formal review, where Boost mailing list members
+ comment on their evaluation of the library.
+
+
+The final "accept" or "reject" decision is made by the
+ [Review Manager](#Review_Manager), based on the
+ review comments received from boost mailing list members.
+
+
+Boost mailing list members are encouraged to submit Formal
+ Review comments:
+
+
+* Publicly on the mailing list.
+* Privately to the Review Manager.
+
+
+Private comments to a library submitter may be helpful to
+ her or him, but won't help the Review Manager reach a decision,
+ so the other forms are preferred.
+
+
+The review period will normally last for 10 days.
+
+
+What to include in
+ Review Comments
+-----------------------------------
+
+
+Your comments may be brief or lengthy, but the
+ Review Manager needs your evaluation of the library. If you
+ identify problems along the way, please note if they are minor,
+ serious, or showstoppers.
+
+
+The goal of a Boost library review is to improve the library
+ through constructive criticism, and at the end a decision must
+ be made: is the library good enough at this point to accept
+ into Boost? If not, we hope to have provided enough
+ constructive criticism for it to be improved and accepted at a
+ later time. The Serialization library is a good example of how
+ constructive criticism resulted in revisions resulting in an
+ excellent library that was accepted in its second review.
+
+
+Here are some questions you might want to answer in your
+ review:
+
+
+* What is your evaluation of the design?
+* What is your evaluation of the implementation?
+* What is your evaluation of the documentation?
+* What is your evaluation of the potential usefulness of
+ the library?
+* Did you try to use the library? With what compiler? Did
+ you have any problems?
+* How much effort did you put into your evaluation? A
+ glance? A quick reading? In-depth study?
+* Are you knowledgeable about the problem domain?
+
+
+And finally, every review should answer this question:
+
+
+* Do you think the library should be accepted as a Boost
+ library? Be sure to say this explicitly so that your other
+ comments don't obscure your overall opinion.
+
+
+Many reviews include questions for library authors. Authors
+ are interested in defending their library against your
+ criticisms; otherwise, they would not have brought their library
+ up for review. If you don't get a response to your question
+ quickly, be patient; if it takes too long or you don't get an
+ answer you feel is sufficient, ask again or try to rephrase the
+ question. Do remember that English is not the native language
+ for many Boosters, and that can cause misunderstandings.
+
+
+E-mail is a poor communication medium, and even if messages
+ rarely get lost in transmission, they often get drowned in the
+ deluge of other messages. Don't assume that an unanswered
+ message means you're being ignored. Given constructively,
+ criticism will be taken better and have more positive effects,
+ and you'll get the answers you want.
+
+
+Results
+-------
+
+
+Within a reasonable time after the conclusion of the comment
+ period, the Review Manager will post a message to the mailing
+ list saying if the library has been accepted or rejected. A
+ rationale is also helpful, but its extent is up to the Review
+ Manager. If there are suggestions, or conditions that must be
+ met before final inclusion, they should be stated. Concerns
+ about the timeliness or quality of the review report should be
+ brought to the Review Wizards off-list.
+
+
+Notes for
+ Review Managers
+--------------------------
+
+
+Before a library can be scheduled for formal review, an
+ active boost member not connected with the library submission
+ must volunteer to be the "Review Manager" for the library.
+ Members may contact a library author on- or off-list to express
+ interest in managing the review. The library author has to accept
+ a person as a review manager.
+
+
+The Review Manager:
+
+
+* Checks the submission to make sure it really is complete
+ enough to warrant formal review. See the [Boost Library Requirements
+ and Guidelines](/development/requirements.html). If necessary, work with the submitter to
+ verify the code compiles and runs correctly on several
+ compilers and platforms.
+* Finalizes the schedule with the Review Wizard and the submitter.
+* Posts a notice of the review schedule on both the regular
+ **[boost mailing list](mailto:boost@lists.boost.org)** and the
+ **[boost-announce](mailto:boost-announce@lists.boost.org) mailing list**.
+	+ The notice should include a brief description of the
+	 library and what it does, to let readers know if the
+	 library is one they are interested in reviewing.
+	+ If the library is known to fail with certain
+	 compilers, please mention them in the review notice so
+	 reviewers with those compilers won't waste time
+	 diagnosing known problems.
+	+ It is advised to send the notice to each mailing list
+	 in a separate e-mail, otherwise online e-mail to news
+	 gateways could get confused.
+* Inspects the Boost [library catalogue](/doc/libs/release/libs/libraries.htm)
+ for libraries which may interact with the new submission.
+ These potential interactions should be pointed out in the
+ review announcement, and the author(s) of these libraries
+ should be privately notified and urged to participate in the
+ review.
+* Urges people to do reviews if they aren't forthcoming.
+* Follows review discussions regarding the library,
+ moderating or answering questions as needed.
+* Asks the [review wizard](#Wizard) for
+ permission to extend the review schedule if it appears that
+ too few reviews will be submitted during the review period.
+* Decides if there is consensus to accept the library and
+ if there are any conditions attached. Consensus is not the
+ same as a vote. The Review Manager has discretion to weigh
+ opinions based on authority or thoughtfulness.
+* Posts a notice of the [review
+ results](#Results) on the regular **[boost](mailto:boost@lists.boost.org)** mailing
+ list, the **[boost-users](mailto:boost-users@lists.boost.org)**
+ mailing list, and the **[boost-announce](mailto:boost-announce@lists.boost.org)**
+ mailing list.
+
+
+In other words, it is the Review Manager's responsibility to
+ make sure the review process works smoothly.
+
+
+Although the review manager is also allowed to review the library,
+ they are expected to serve the interests of the Boost users.
+ Since the review manager may have a (strong) opinion about the library,
+ it is recommended as a matter of principle they do not share their opinion
+ until the very end of the review. Possibly, until the summary of reviews.
+ The review manager will make the final choice and announcing an opinion early
+ in the process could negatively affect the review process.
+
+
+Notes for Library
+ Submitters
+-----------------------------
+
+
+See [Submission
+ Process](/development/submissions.html) for a description of the steps a library developer
+ goes through to get a library accepted by Boost.
+
+
+First, the library author should accept a review manager.
+ If they feel, for whatever reason, a candidate for a review manager
+ is not competent or fair, they should not accept such candidate.
+
+
+A proposed library should remain stable during the review
+ period; it will just confuse and irritate reviewers if there
+ are numerous changes. It is, however, useful to upload fixes
+ for serious bugs right away, particularly those which prevent
+ reviewers from fully evaluating the library. Post a notice of
+ such fixes on the mailing list.
+
+
+Library improvements suggested by reviewers should normally
+ be held until after the completion of review period. If the
+ suggested changes might affect the reviewer's judgments, post a
+ notice of the pending change on the mailing list.
+
+
+Library
+ Maintainer's Rights and Responsibilities
+-------------------------------------------------
+
+
+By submitting a library to boost, you accept responsibility
+ for maintaining your library or finding a qualified volunteer
+ to serve as maintainer. You must be willing to put your library
+ and documentation under a Boost-compatible license.
+
+
+You will be expected to respond to reasonable bug reports
+ and questions on time and to participate as needed
+ in discussions of your library on the boost mailing lists.
+
+
+You are free to change your library in any way you wish, and
+ you are encouraged to actively make improvements. However, peer
+ review is an important part of the Boost process and as such
+ you are also encouraged to get feedback from the boost
+ community before making substantial changes to the interface of
+ an accepted library.
+
+
+If at some point you no longer wish to serve as maintainer
+ of your library, it is your responsibility to make this known
+ to the boost community and to find another individual to take
+ your place.
+
+
+Libraries which have been abandoned will be put in care of
+ the [Community
+ Maintenance Team](https://svn.boost.org/trac/boost/wiki/CommunityMaintenance).
+
+
+Review Wizards
+--------------
+
+
+The Review Wizards coordinate the formal review
+ schedule:
+
+
+* When a formal review is requested for a library:
+	+ Approve the review manager based on initial acceptance
+	 by the library submitter, their participation in the Boost
+	 community, including the mailing list, previous reviews,
+	 and other forums.
+	+ Suggest a schedule, after checking (via private
+	 email) the availability of the review manager and library
+	 author.
+	+ Finalize the schedule, once the review manager
+	 verifies the library is ready for review.
+	+ Resolve schedule slips or other issues with review
+	 managers and submitters.
+* Maintains a schedule of both past and pending reviews, in
+ the form of the [Review
+ Schedule](review_schedule.html) web page.
+* Resolves questions from review managers and library
+ submitters, who sometimes want a third opinion on questions
+ such as "Should we extend the review period because
+ ...?"
+* Monitors the general review process, and makes minor
+ adjustments as needed, or queries the list about possible
+ major adjustments.
+
+
+The role of Boost Review Wizard is currently played by:
+
+
+* Mateusz Loskot (mateusz at loskot dot net)
+* John Phillips (johnphillipsithaca at gmail dot com)
+
+
+Past Review Wizards (we thank you for your service):
+
+
+* Ronald Garcia
+* Tom Brinkman
+* Thomas Witt
+
+
+Fast Track
+ Reviews
+-------------------
+
+
+To qualify for fast track review:
+
+
+* The component must be small.
+* The technique must be already in use in Boost libraries
+ and the new component provides a common implementation.
+* A full Boost-conformant implementation is available in
+ the sandbox.
+* The Review Wizard determines that the proposal qualifies
+ for fast track review.
+
+
+Procedure:
+
+
+* The Boost Review Wizard posts a review announcement to
+ the main Boost developer's list. The fast track review period will
+ normally last for 5 days. No two fast-track reviews will run
+ in parallel. Fast track reviews may run during full reviews,
+ though generally, this is to be avoided.
+* After the review period ends, the submitter will post a
+ review summary containing proposed changes to the reviewed
+ implementation.
+* The Review Wizard will accept or reject the proposed
+ library and proposed changes.
+* After applying the proposed changes, the component is
+ checked into the repository like any other library.
+
+
+Mini-Reviews
+------------
+
+
+If a review results in conditions on acceptance, the review
+ manager may request a Mini-Review to determine if the
+ conditions have been met. The Mini-Review is usually conducted
+ by the same review manager.
+
+
+
+
+
+
+
+
+

community/sandbox.html

@@ -0,0 +1,72 @@
+---
+title: Boost Sandbox
+copyright: Rene Rivera 2007.
+revised: 
+---
+
+
+Boost Sandbox
+
+
+
+Boost Sandbox
+=============
+
+When boost was developed using subversion, the Boost Sandbox
+ contained unreviewed code that is intended to eventually become
+ a part of the Boost libraries. New libraries should be
+ developed separately as [git
+ modules](https://svn.boost.org/trac/boost/wiki/ModularBoost), and existing projects should be [moved to
+ GitHub](https://svn.boost.org/trac/boost/wiki/ExtractSandbox). The sandbox remains as a historical record.
+
+
+Accessing the Boost Sandbox
+---------------------------
+
+
+The Boost Sandbox lives at <https://svn.boost.org/svn/boost/sandbox>
+ within the old Boost Subversion repository.
+
+
+Organization
+------------
+
+
+Because there were typically many projects in the sandbox at
+ any one time (in various stages of development), the sandbox
+ should have been organized by project. Each project should have
+ had its own subdirectory inside sandbox. For example,
+ an XML library would reside in sandbox/xml. Inside
+ that project-specific subdirectory, the project would be
+ organized like any other Boost library, with a boost
+ subdirectory (for headers) and libs subdirectory (for
+ source code, build files, and documentation). Our hypothetical
+ XML project would likely have had the following structure:
+
+
+* sandbox/xml/
+	+ boost/ - Contains xml.hpp, which
+	 includes all of the headers from xml/
+		- xml/ - Contains Boost.XML headers
+	+ libs/
+		- xml/
+			* build/ - Contains Jamfiles
+			 to build Boost.XML
+			* doc/ - Contains documentation for
+			 Boost.XML
+			* src/ - Contains Boost.XML compiled
+			 source files
+
+
+Many existing projects in the sandbox didn't follow this
+ structure, opting to place headers in sandbox/boost
+ and supporting files in sandbox/libs.
+
+
+
+
+
+
+
+
+

development/_template_.html

@@ -0,0 +1,24 @@
+---
+title: Boost C++ Libraries
+copyright: Rene Rivera 2007.
+revised: 
+---
+
+
+Boost C++ Libraries
+
+
+
+Boost C++ Libraries
+===================
+
+{stuff}
+
+
+
+
+
+
+
+
+

development/borland_cpp.html

@@ -0,0 +1,405 @@
+---
+title: Portability Hints: Borland C++ 5.5.1
+copyright: 
+revised: 2007-10-22 22:55:52 +0100
+---
+
+
+Portability Hints: Borland C++ 5.5.1
+
+
+
+Portability Hints: Borland C++ 5.5.1
+====================================
+
+It is a general aim for boost libraries to be [portable](/development/requirements.html#Portability). The
+ primary means for achieving this goal is to adhere to ISO
+ Standard C++. However, ISO C++ is a broad and complex standard
+ and most compilers are not fully conformant to ISO C++ yet. In
+ order to achieve portability in the light of this restriction,
+ it seems advisable to get acquainted with those language
+ features that some compilers do not fully implement yet.
+
+
+This page gives portability hints on some language features
+ of the Borland C++ version 5.5.1 compiler. Furthermore, the
+ appendix presents additional problems with Borland C++ version
+ 5.5. Borland C++ 5.5.1 is a freely available command-line
+ compiler for Win32 available at <http://www.borland.com/>.
+
+
+Each entry in the following list describes a particular
+ issue, complete with sample source code to demonstrate the
+ effect. Most sample code herein has been verified to compile
+ with gcc 2.95.2 and Comeau C++ 4.2.44.
+
+
+Preprocessor symbol
+-------------------
+
+
+The preprocessor symbol `__BORLANDC__` is defined
+ for all Borland C++ compilers. Its value is the version number
+ of the compiler interpreted as a hexadecimal number. The
+ following table lists some known values.
+
+| Compiler | `__BORLANDC__` value |
+| --- | --- |
+| Borland C++ Builder 4 | 0x0540 |
+| Borland C++ Builder 5 | 0x0550 |
+| Borland C++ 5.5 | 0x0550 |
+| Borland C++ 5.5.1 | 0x0551 |
+| Borland C++ Builder 6 | 0x0560 |
+
+
+Core Language
+-------------
+
+
+### [using-directive] Mixing `using`-declarations
+ and `using`-directives
+
+
+Mixing `using`-directives (which refer to whole
+ namespaces) and namespace-level `using`-declarations
+ (which refer to individual identifiers within foreign
+ namespaces) causes ambiguities where there are none. The
+ following code fragment illustrates this:
+```
+
+namespace N {
+  int x();
+}
+
+using N::x;
+using namespace N;
+
+int main()
+{
+  &x;     // Ambiguous overload
+}
+
+```
+
+### [using template] `using`-declarations for class
+ templates
+
+
+Identifiers for class templates can be used as arguments to
+ `using`-declarations as any other identifier.
+ However, the following code fails to compile with Borland
+ C++:
+```
+
+template<class T>
+class X { };
+
+namespace N
+{
+  // "cannot use template 'X<T>' without specifying specialization parameters"
+  using ::X;
+};
+
+```
+
+### [template const arg] Deduction of constant arguments to
+ function templates
+
+
+Template function type deduction should omit top-level
+ constness. However, this code fragment instantiates "f<const
+ int>(int)":
+```
+
+template<class T>
+void f(T x)
+{
+        x = 1;  // works
+        (void) &x;
+        T y = 17;
+        y = 20;  // "Cannot modify a const object in function f<const int>(int)"
+        (void) &y;
+}
+
+int main()
+{
+        const int i = 17;
+        f(i);
+}
+
+```
+
+### [function address] Resolving addresses of overloaded
+ functions
+
+
+Addresses of overloaded functions are not in all contexts
+ properly resolved (std:13.4 [over.over]); here is a small
+ example:
+```
+
+template<class Arg>
+void f( void(\*g)(Arg) );
+
+void h(int);
+void h(double);
+
+template<class T>
+void h2(T);
+
+int main()
+{
+  void (\*p)(int) = h;            // this works (std:13.4-1.1)
+  void (\*p2)(unsigned char) = h2;    // this works as well (std:13.4-1.1)
+  f<int>(h2);  // this also works (std:13.4-1.3)
+
+  // "Cannot generate template specialization from h(int)",
+  // "Could not find a match for f<Arg>(void (\*)(int))"
+  f<double>(h);   // should work (std:13.4-1.3)
+
+  f( (void(\*)(double))h);  // C-style cast works (std:13.4-1.6 with 5.4)
+
+  // "Overloaded 'h' ambiguous in this context"
+  f(static\_cast<void(\*)(double)>(h)); // should work (std:13.4-1.6 with 5.2.9)
+}
+
+```
+
+**Workaround:** Always use C-style casts when
+ determining addresses of (potentially) overloaded
+ functions.
+
+
+### [string conversion] Converting `const char *` to
+ `std::string`
+
+
+Implicitly converting `const char *` parameters
+ to `std::string` arguments fails if template
+ functions are explicitly instantiated (it works in the usual
+ cases, though):
+```
+
+#include <string>
+
+template<class T>
+void f(const std::string & s)
+{}
+
+int main()
+{
+  f<double>("hello");  // "Could not find a match for f<T>(char \*)"
+}
+
+
+```
+
+**Workaround:** Avoid explicit template
+ function instantiations (they have significant problems with
+ Microsoft Visual C++) and pass default-constructed unused dummy
+ arguments with the appropriate type. Alternatively, if you wish
+ to keep to the explicit instantiation, you could use an
+ explicit conversion to `std::string` or declare the
+ template function as taking a `const char *`
+ parameter.
+
+
+### [template value defaults] Dependent default arguments for
+ template value parameters
+
+
+Template value parameters which default to an expression
+ dependent on previous template parameters don't work:
+```
+
+template<class T>
+struct A
+{
+  static const bool value = true;
+};
+
+// "Templates must be classes or functions", "Declaration syntax error"
+template<class T, bool v = A<T>::value>
+struct B {};
+
+int main()
+{
+  B<int> x;
+}
+
+
+```
+
+**Workaround:** If the relevant non-type
+ template parameter is an implementation detail, use inheritance
+ and a fully qualified identifier (for example,
+ ::N::A<T>::value).
+
+
+### [function partial ordering] Partial ordering of function
+ templates
+
+
+Partial ordering of function templates, as described in
+ std:14.5.5.2 [temp.func.order], does not work:
+```
+
+#include <iostream>
+
+template<class T> struct A {};
+
+template<class T1>
+void f(const A<T1> &)
+{
+  std::cout << "f(const A<T1>&)\n";
+}
+
+template<class T>
+void f(T)
+{
+  std::cout << "f(T)\n";
+}
+
+int main()
+{
+  A<double> a;
+  f(a);   // output: f(T)  (wrong)
+  f(1);   // output: f(T)  (correct)
+}
+
+```
+
+**Workaround:** Declare all such functions
+ uniformly as either taking a value or a reference
+ parameter.
+
+
+### [instantiate memfun ptr] Instantiation with member function
+ pointer
+
+
+When directly instantiating a template with some member
+ function pointer, which is itself dependent on some template
+ parameter, the compiler cannot cope:
+```
+
+template<class U> class C { };
+template<class T>
+class A
+{
+  static const int v = C<void (T::\*)()>::value;
+};
+
+```
+
+**Workaround:** Use an intermediate
+ `typedef`:
+```
+
+template<class U> class C { };
+template<class T>
+class A
+{
+  typedef void (T::\*my\_type)();
+  static const int v = C<my\_type>::value;
+};
+
+```
+
+(Extracted from e-mail exchange of David Abrahams, Fernando
+ Cacciola, and Peter Dimov; not actually tested.)
+
+
+Library
+-------
+
+
+### [cmath.abs] Function `double std::abs(double)`
+ missing
+
+
+The function `double std::abs(double)` should be
+ defined (std:26.5-5 [lib.c.math]), but it is not:
+```
+
+#include <cmath>
+
+int main()
+{
+  double (\*p)(double) = std::abs;  // error
+}
+
+```
+
+Note that `int std::abs(int)` will be used
+ without warning if you write `std::abs(5.1)`.
+
+
+Similar remarks apply to seemingly all of the other standard
+ math functions, where Borland C++ fails to provide
+ `float` and `long double` overloads.
+
+
+**Workaround:** Use `std::fabs`
+ instead if type genericity is not required.
+
+
+Appendix: Additional issues with Borland C++ version
+ 5.5
+---------------------------------------------------------
+
+
+These issues are documented mainly for historic reasons. If
+ you are still using Borland C++ version 5.5, you are strongly
+ encouraged to obtain an upgrade to version 5.5.1, which fixes
+ the issues described in this section.
+
+
+### [inline friend] Inline friend functions in template
+ classes
+
+
+If a friend function of some class has not been declared
+ before the friend function declaration, the function is
+ declared at the namespace scope surrounding the class
+ definition. Together with class templates and inline
+ definitions of friend functions, the code in the following
+ fragment should declare (and define) a non-template function
+ "bool N::f(int,int)", which is a friend of class
+ N::A<int>. However, Borland C++ v5.5 expects the function
+ f to be declared beforehand:
+```
+
+namespace N {
+template<class T>
+class A
+{
+  // "f is not a member of 'N' in function main()"
+  friend bool f(T x, T y) { return x < y; }
+};
+}
+
+int main()
+{
+  N::A<int> a;
+}
+
+```
+
+This technique is extensively used in boost/operators.hpp.
+ Giving in to the wish of the compiler doesn't work in this
+ case, because then the "instantiate one template, get lots of
+ helper functions at namespace scope" approach doesn't work
+ anymore. Defining BOOST\_NO\_OPERATORS\_IN\_NAMESPACE (a define
+ BOOST\_NO\_INLINE\_FRIENDS\_IN\_CLASS\_TEMPLATES would match this
+ case better) works around this problem and leads to another
+ one, see [using-template].
+
+
+
+
+
+
+html)
+
+

development/bugs.html

@@ -0,0 +1,50 @@
+---
+title: Bugs
+copyright: <a href="/users/people/aleksey_gurtovoy.
+revised: 
+---
+
+
+Bugs
+
+
+
+Reporting Boost bugs
+====================
+
+
+1. If you know where to look in the source code, 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 [git repositories](https://github.com/boostorg/wiki/wiki/Getting-Started).
+2. [Search the issues](https://github.com/boostorg/)
+ on GitHub to make sure we don't already know about the bug.
+ If we do, you can add further information to an existing bug ticket.
+3. [Create a new issues](https://github.com/boostorg/)
+ in the repository of the particular library of your interest.
+
+
+If possible,
+
+
+	* Describe the problem carefully, including steps required to
+	 reproduce it by a library maintainers.
+	* Attach a *minimal* and *complete*
+	 program that reproduces the problem. Aside from helping
+	 the library maintainer fix the problem, you may find
+	 the bug in your own code, which can avoid a costly
+	 delay waiting for a response.
+If You Have a Fix for the Bug
+-----------------------------
+After completing the steps above, please submit a patch
+ or a pull request as described in
+ [the wiki](https://svn.boost.org/trac/boost/wiki/StartModPatchAndPullReq "Getting Started with Patches and Pull Requests").
+
+
+
+
+
+Copyright [Aleksey
+ Gurtovoy](/users/people/aleksey_gurtovoy.html) 2002
+
+

development/design_faq.html

@@ -0,0 +1,60 @@
+---
+title: Boost Website Design FAQ
+copyright: Rene Rivera 2006.
+revised: 
+---
+
+
+Boost Website Design FAQ
+
+
+
+Boost Website Design FAQ
+========================
+
+* Links
+	+ [Why are links
+	 "underlined"?](#faq-links-1)
+	+ [Why are not "standard"
+	 underlines used for links?](#faq-links-2)
+	+ [Why are not all links
+	 underlined?](#faq-links-3)
+
+
+Why are links
+ "underlined"? The website follows some simple design
+ principles to make the site as widely accessible as practical.
+ The style for links within document text are underlined to have
+ a non-color, clear, visual indicator that it is a link.
+ Underlines provide the most familiar indicator to people
+ because of the historical default usage by web browsers.
+
+
+Why are not
+ "standard" underlines used for links? The use of the
+ bottom border provides for considerable more flexibility in
+ style than the underline font style. It is important to have
+ such freedom to be able to indicate the various states links
+ can be in. In the case of the Boost design the bottom border
+ underline is used to represent the difference between internal
+ vs. external links, and between visited and unvisited links.
+ All of which are orthogonal to the text being a link.
+
+
+Why are not all
+ links underlined? When it is clear from the context that
+ the text is a link the underline is ommited to reduce visual
+ clutter, as this is also within a context under which the text
+ is already a collection of links. For such situations the
+ design uses a link box context. All such links are placed
+ within a light grey bordered box to indicate that the items
+ within it are links.
+
+
+
+
+
+
+
+
+

development/exemplar.html

@@ -0,0 +1,314 @@
+---
+title: Boost C++ Libraries
+copyright: Rene Rivera 2005.
+revised: 
+---
+
+
+Boost C++ Libraries
+
+
+
+Website Exemplars
+=================
+
+This is both a test page and a guide as to the various
+ styled elements available in the Boost web pages. And for self
+ reference this is a [class="section-body"] div inside a
+ [class="section"] div. Each [class="section"] div should have a
+ corresponding "id", in this case the section is [id="intro"].
+ Feel free to copy elements from here onto other pages to
+ quickly get the structure you want. **And of more import
+ please update this page if you add new content styles as it
+ helps everyone with the website documentation.**
+
+
+Section [class="section-title"]
+===============================
+
+Simple paragraph inside the section body
+ [class="section-body"].
+
+
+Heading 2
+---------
+
+
+![SourceForge.net](http://sourceforge.net/sflogo.php?group_id=7586&type=3)The image to the
+ left uses a [class="left-inset"] as a shorthand for any
+ floating inset element aligned at both top and left edges.
+ — Lorem ipsum dolor sit amet, consectetuer adipiscing
+ elit. Duis ligula lorem, consequat eget, tristique nec, auctor
+ quis, purus. Vivamus ut sem. Fusce aliquam nunc vitae purus.
+ Aenean viverra malesuada libero. Fusce ac quam. Donec neque.
+ Nunc venenatis enim nec quam. Cras faucibus, justo vel accumsan
+ aliquam, tellus dui fringilla quam, in condimentum augue lorem
+ non tellus. Pellentesque id arcu non sem placerat iaculis.
+ Curabitur posuere, pede vitae lacinia accumsan, enim nibh
+ elementum orci, ut volutpat eros sapien nec sapien. Suspendisse
+ neque arcu, ultrices commodo, pellentesque sit amet, ultricies
+ ut, ipsum. Mauris et eros eget erat dapibus mollis. Mauris
+ laoreet posuere odio. Nam ipsum ligula, ullamcorper eu,
+ fringilla at, lacinia ut, augue. Nullam nunc.
+
+
+### Heading 3
+
+
+![SourceForge.net](http://sourceforge.net/sflogo.php?group_id=7586&type=4)This image uses a
+ [class="right-inset"] to as a mirror of the previous section
+ for a floating inset element aligned to top and right edges.
+ — Sed et lectus in massa imperdiet tincidunt. Praesent
+ neque tortor, sollicitudin non, euismod a, adipiscing a, est.
+ Mauris diam metus, varius nec, faucibus at, faucibus
+ sollicitudin, lectus. Nam posuere felis ac urna. Vestibulum
+ tempor vestibulum urna. Nullam metus. Vivamus ac purus. Nullam
+ interdum ullamcorper libero. Morbi vehicula imperdiet justo.
+ Etiam mollis fringilla ante. Donec et dui. Class aptent taciti
+ sociosqu ad litora torquent per conubia nostra, per inceptos
+ hymenaeos. Etiam mi libero, luctus nec, blandit ac, rutrum ac,
+ lectus.
+
+
+#### Heading 4
+
+
+These are, hopefully all, the standard text markup styles.
+ Note, these are *not* structural markup elements. I.e.
+ these are the styles one sees to mark parts of the text inside
+ a paragraph, like the "not" in the second sentence of this
+ paragraph.
+EM:
+Indicates *emphasis*.
+STRONG:
+Indicates **stronger emphasis**.
+CITE:
+Contains a citation or a reference to other
+ sources.
+DFN:
+Indicates that this is the defining instance
+ of the enclosed term.
+CODE:
+Designates a fragment of `computer code`.
+SAMP:
+Designates `sample output` from programs,
+ scripts, etc.
+KBD:
+Indicates `text to be entered` by the user.
+VAR:
+Indicates an instance of a variable or program
+ argument.
+ABBR:
+Indicates an abbreviated form (e.g., WWW,
+ HTTP, URI, Mass.,
+ etc.).
+ACRONYM:
+Indicates an acronym (e.g., WAC,
+ radar, etc.).
+Q:
+Indicates a quotation possibly with
+ sub-quotes.
+SUB and SUP:
+Indicates either subscripts or
+ superscripts.
+INS and DEL:
+
+ Used to markup sections of the document that have been
+ inserted or ~~deleted~~ with respect to a
+ different version of a document.
+ 
+
+##### Heading 5
+
+
+There are a variety of HTML structural elements. This means
+ that they do not tipically show with text flow. Bu tinstead
+ show as individual block elements. This paragraph being an
+ example. And the somewhat overused BLOCKQUOTE being
+ another:
+> 
+> Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
+>  Duis ligula lorem, consequat eget, tristique nec, auctor
+>  quis, purus. Vivamus ut sem. Fusce aliquam nunc vitae purus.
+>  Aenean viverra malesuada libero. Fusce ac quam. Donec neque.
+>  Nunc venenatis enim nec quam. Cras faucibus, justo vel
+>  accumsan aliquam, tellus dui fringilla quam, in condimentum
+>  augue lorem non tellus. Pellentesque id arcu non sem placerat
+>  iaculis. Curabitur posuere, pede vitae lacinia accumsan, enim
+>  nibh elementum orci, ut volutpat eros sapien nec sapien.
+>  Suspendisse neque arcu, ultrices commodo, pellentesque sit
+>  amet, ultricies ut, ipsum. Mauris et eros eget erat dapibus
+>  mollis. Mauris laoreet posuere odio. Nam ipsum ligula,
+>  ullamcorper eu, fringilla at, lacinia ut, augue. Nullam
+>  nunc.
+> 
+> 
+> 
+
+
+The Boost pages avoid the use of tables as a layout
+ mechanism. This helps, and hurts, in a variety of ways. The
+ most important benefit is the wider semantic access of the
+ content. It means that the largest set of browsers will
+ interpret tables as what they are; tabular content. The
+ following convenient sample comes from the helpful [HTML4 W3 standard](http://www.w3.org/TR/html4/struct/tables.html#h-11.5):
+
+
+ CODE-PAGE SUPPORT IN MICROSOFT WINDOWS
+ 
+| Code-Page ID | Name | ACP | OEMCP | Windows NT 3.1 | Windows NT 3.51 | Windows 95 |
+| --- | --- | --- | --- | --- | --- | --- |
+| 1200 | Unicode (BMP of ISO/IEC-10646) |  |  | X | X | \* |
+| 1250 | Windows 3.1 Eastern European | X |  | X | X | X |
+| 1251 | Windows 3.1 Cyrillic | X |  | X | X | X |
+| 1252 | Windows 3.1 US (ANSI) | X |  | X | X | X |
+| 1253 | Windows 3.1 Greek | X |  | X | X | X |
+| 1254 | Windows 3.1 Turkish | X |  | X | X | X |
+| 1255 | Hebrew | X |  |  |  | X |
+| 1256 | Arabic | X |  |  |  | X |
+| 1257 | Baltic | X |  |  |  | X |
+| 1361 | Korean (Johab) | X |  |  | \*\* | X |
+| 437 | MS-DOS United States |  | X | X | X | X |
+| 708 | Arabic (ASMO 708) |  | X |  |  | X |
+| 709 | Arabic (ASMO 449+, BCON V4) |  | X |  |  | X |
+| 710 | Arabic (Transparent Arabic) |  | X |  |  | X |
+| 720 | Arabic (Transparent ASMO) |  | X |  |  | X |
+
+
+###### Heading 6
+
+
+One of the most important elements of HTML is the hypertext
+ link. In the Boost pages all [links](/) are treated
+ in a similar, consistent, manner regardless of context as much
+ as possible. Stylistic variations are present to account for
+ color contrast differences in the context. For example the
+ links in the header, and footer use different colors to match
+ the text color and contrast as much as possible with the
+ respective backgrounds. Within section content, like here, the
+ links also provide differing look & feel based on wether
+ they target the [Boost web site](/), or some
+ [external web
+ site [class="external"]](http://www.google.com/). Since most of the time links are
+ internal, that is the default semantic. External links need to
+ be decorated with [class="external"].
+
+
+* One
+---
+
+
+This a "directory" unordered list [ul
+ class="directory"]. It is styled to show a list of short
+ items in as compact a form as possible. Currently that
+ means the items are arrayed in two columns and items are
+ packed to read left-to-right and top-to-bottom.
+* Two
+---
+
+
+Even though this an unordered list, one can also arrange
+ any block elements in this way. The top container needs to
+ be a [class="directory"] and the interior items
+ [class="directory-item"].
+
+
+Unordered Lists [ul]
+--------------------
+
+
+This type of list is one of the most commonly used
+ structural elements used. It's used for directory listing,
+ history listings, table of contests, and many more. The goal is
+ to classify the various lists by type with a
+ [class="type-here"] attribute on the list [ul]. Please resist
+ the urge to use a classification just because it has the
+ particular look you want. As at some future point the look will
+ change and you will have no say in the effect of the particular
+ context.
+
+
+### Default [ul]
+
+
+* Item 1
+	+ Subitem 1a
+		- Subitem 1a1
+		- Subitem 1a2
+	+ Subitem 1b
+* Item 2
+	+ Subitem 2a
+	+ Subitem 2b
+
+
+### Directory [ul class="directory"]
+
+
+* Item 1
+	+ Subitem 1a
+		- Subitem 1a1
+		- Subitem 1a2
+	+ Subitem 1b
+* Item 2
+	+ Subitem 2a
+	+ Subitem 2b
+
+
+### Table of contents [ul class="toc"]
+
+
+* [Item 1](#)
+	+ [Subitem 1a](#)
+	+ [Subitem 1b](#)
+* [Item 2](#)
+	+ [Subitem 2a](#)
+	+ [Subitem 2b](#)
+
+
+### History [ul class="history"]
+
+
+* Item 1
+	+ Subitem 1a
+	+ Subitem 1b
+* Item 2
+	+ Subitem 2a
+	+ Subitem 2b
+
+
+### Menus [ul class="menu"]
+
+
+* [Item 1](#)
+* [Item 2](#)
+
+
+### Tree [ul class="tree"]
+
+
+* Item 1
+	+ Subitem 1a
+		- Subitem 1a1
+		- Subitem 1a2
+	+ Subitem 1b
+* Item 2
+	+ Subitem 2a
+	+ Subitem 2b
+
+
+Preformatted [pre]
+------------------
+
+
+This is often used to show code examples, or more accurately
+ fixed examples. For example the [Boost Software License](/users/license.html):
+```
+```
+
+
+
+
+
+
+
+

development/header.html

@@ -0,0 +1,108 @@
+---
+title: Boost Header policy
+copyright: Beman Dawes 1998.
+revised: 2007-10-22 22:55:52 +0100
+---
+
+
+Boost Header policy
+
+
+
+Boost Header policy
+===================
+
+Header files are the place where a library comes into
+ contact with user code and other libraries. To co-exist
+ peacefully and productively, headers must be "good
+ neighbors".
+
+
+Here are the standards for boost headers. Many of these are
+ also reasonable guidelines for general use.
+
+
+* Header filenames should have a .hpp (lowercase)
+ extension.
+* Unless multiple inclusion is intended, wrap the header in
+ #ifndef guards. Use a naming convention that minimizes the
+ chance of clashes with macro names from other's code. The
+ [sample header](#SampleHeader) uses the Boost
+ convention of all uppercase letters, with the header name
+ prefixed by the namespace name, and suffixed with HPP,
+ separated by underscores.
+* Wrap the header contents in a namespace to prevent global
+ namespace pollution. The namespace approach to pollution
+ control is strongly preferred to older approaches such as
+ adding funny prefixes to global names. Libraries which are
+ designed to work well with other Boost libraries should be
+ placed in namespace boost.
+* Make sure that a translation unit consisting of just the
+ contents of the header file will compile successfully.
+* Place the header file in a sub-directory to prevent
+ conflict with identically named header files in other
+ libraries. The parent directory is added to the compiler's
+ include search path. Then both your code and user code
+ specifies the sub-directory in #include directives.
+ Thus the header [sample header](#SampleHeader)
+ would be included by #include
+ <boost/furball.hpp>. (Note, including from current
+ file directory using #include "furball.hpp" syntax
+ is discouraged .)
+* The preferred ordering for class definitions is public
+ members, protected members, and finally private members.
+* Include the boost/config.hpp [configuration
+ header](/doc/libs/release/libs/config/config.htm) if there is a need to deal with compiler or
+ platform configuration issues.
+
+
+Sample
+ Header
+--------------
+```
+
+//  Boost general library furball.hpp header file ---------------------------//
+
+  < *html) >
+
+//  See https://www.boost.org/ for latest version.
+
+#ifndef BOOST\_FURBALL\_HPP
+#define BOOST\_FURBALL\_HPP
+
+namespace boost {
+
+//  Furball class declaration  -----------------------------------------------//
+
+  class furball
+  {
+    public: 
+      void throw\_up();
+    private:
+      int whatever;
+  };  // furball
+
+} // namespace
+
+#endif  // include guard
+
+```
+
+Coding Style
+------------
+
+
+The alert reader will have noticed that the [sample header](#SampleHeader) employs a certain coding
+ style for indentation, positioning braces, commenting ending
+ braces, and similar formatting issues. These stylistic issues
+ are viewed as personal preferences and are not part of the
+ Boost Header Policy.
+
+
+
+
+
+
+
+
+

development/index.html

@@ -0,0 +1,71 @@
+---
+title: Boost Development
+copyright: Rene Rivera 2007.
+revised: 
+---
+
+
+Boost Development
+
+
+/\*<![CDATA[\*/
+ #content .section .openhub > div {
+ background: transparent !important;
+ }
+ #content .section .openhub table {
+ background: transparent !important;
+ clear: none !important;
+ border-spacing: 0em !important;
+ margin-bottom: 0.25em !important;
+ }
+ #content .section .openhub table tr td {
+ border: none !important;
+ }
+ #content .section #openhub-cost table tr td {
+ background: transparent !important;
+ border-bottom: 1px #DDD solid !important;
+ }
+ #content .section .openhub img {
+ border: none !important;
+ padding: 0em !important;
+ }
+ /\*]]>\*/
+ 
+
+
+Development
+===========
+
+Boost sources are on
+ [GitHub](https://github.com/boostorg).
+
+
+Boost developers constitute a wide array of people
+ throughout much of the world. Over the years much work has gone
+ into the quantity and quality of the C++ libraries and tools
+ that make up Boost. There are many ways to become part of the
+ Boost developer community, all starting with getting involved
+ in the development discussion. But if you are looking for an
+ "easy" place to get your feet wet is to volunteer [testing](testing.html) resources. The wonderful people at
+ [Black Duck
+ Open Hub](http://www.openhub.net/) provide a peek into what goes into Boost:
+
+
+* 
+* 
+
+Release Schedule
+================
+
+Below is a community maintained calendar of Boost related
+ events. The release managers try to keep the release related
+ portion of the calendar up to date.
+
+
+
+
+
+
+
+
+

development/int_const_guidelines.html

@@ -0,0 +1,423 @@
+---
+title: Coding Guidelines for Integral Constant Expressions
+copyright: Dr John Maddock 2001.
+revised: 2007-10-22 22:55:52 +0100
+---
+
+
+Coding Guidelines for Integral Constant Expressions
+
+
+
+Coding Guidelines for Integral Constant Expressions
+===================================================
+
+Integral Constant Expressions are used in many places in
+ C++; as array bounds, as bit-field lengths, as enumerator
+ initialisers, and as arguments to non-type template parameters.
+ However many compilers have problems handling integral constant
+ expressions; as a result of this, programming using non-type
+ template parameters in particular can be fraught with
+ difficulty, often leading to the incorrect assumption that
+ non-type template parameters are unsupported by a particular
+ compiler. This short article is designed to provide a set of
+ guidelines and workarounds that, if followed, will allow
+ integral constant expressions to be used in a manner portable
+ to all the compilers currently supported by boost. Although
+ this article is mainly targeted at boost library authors, it
+ may also be useful for users who want to understand why boost
+ code is written in a particular way, or who want to write
+ portable code themselves.
+
+
+What is an Integral Constant Expression?
+----------------------------------------
+
+
+Integral constant expressions are described in section 5.19
+ of the standard, and are sometimes referred to as "compile time
+ constants". An integral constant expression can be one of the
+ following:
+
+
+1. A literal integral value, for example `0u` or
+ `3L`.
+2. An enumerator value.
+3. Global integral constants, for example:
+ 
+```
+
+const int my\_INTEGRAL\_CONSTANT = 3;
+
+```
+4. Static member constants, for example:
+ 
+```
+
+struct myclass
+{ static const int value = 0; };
+
+```
+5. Member enumerator values, for example:
+ 
+```
+
+struct myclass
+{ enum{ value = 0 }; };
+
+```
+6. Non-type template parameters of integral or enumerator
+ type.
+7. The result of a `sizeof` expression, for
+ example:
+ 
+```
+
+sizeof(foo(a, b, c))
+
+```
+8. The result of a `static_cast`, where the
+ target type is an integral or enumerator type, and the
+ argument is either another integral constant expression, or a
+ floating-point literal.
+9. The result of applying a binary operator to two integral
+ constant expressions:
+ 
+```
+
+INTEGRAL\_CONSTANT1 op INTEGRAL\_CONSTANT2
+
+```
+provided that the operator is not an assignment operator, or comma
+operator.
+10. The result of applying a unary operator to an integral
+ constant expression:
+ 
+```
+
+op INTEGRAL\_CONSTANT1
+
+```
+provided that the operator is not the increment or decrement operator.
+
+
+Coding Guidelines
+-----------------
+
+
+The following guidelines are declared in no particular order
+ (in other words you need to obey all of them - sorry!), and may
+ also be incomplete, more guidelines may be added as compilers
+ change and/or more problems are encountered.
+
+
+### When declaring constants that are class members always use
+ the macro `BOOST_STATIC_CONSTANT.`
+```
+
+template <class T>
+struct myclass
+{
+   BOOST\_STATIC\_CONSTANT(int, value = sizeof(T));
+};
+
+```
+
+Rationale: not all compilers support inline initialisation
+ of member constants, others treat member enumerators in strange
+ ways (they're not always treated as integral constant
+ expressions). The BOOST\_STATIC\_CONSTANT macro uses the most
+ appropriate method for the compiler in question.
+
+
+### Don't declare integral constant expressions whose type is
+ wider than int.
+
+
+Rationale: while in theory all integral types are usable in
+ integral constant expressions, in practice many compilers limit
+ integral constant expressions to types no wider than
+ `int`.
+
+
+### Don't use logical operators in integral constant
+ expressions; use template meta-programming instead.
+
+
+The header `<boost/type_traits/ice.hpp>`
+ contains a number of workaround templates, that fulfil the role
+ of logical operators, for example instead of:
+```
+
+INTEGRAL\_CONSTANT1 || INTEGRAL\_CONSTANT2
+
+```
+
+Use:
+```
+
+::boost::type\_traits::ice\_or<INTEGRAL\_CONSTANT1,INTEGRAL\_CONSTANT2>::value
+
+```
+
+Rationale: A number of compilers (particularly the Borland
+ and Microsoft compilers), tend to not to recognise integral
+ constant expressions involving logical operators as genuine
+ integral constant expressions. The problem generally only shows
+ up when the integral constant expression is nested deep inside
+ template code, and is hard to reproduce and diagnose.
+
+
+### Don't use any operators in an integral constant expression
+ used as a non-type template parameter
+
+
+Rather than:
+```
+
+typedef myclass<INTEGRAL\_CONSTANT1 ==
+              INTEGRAL\_CONSTANT2> mytypedef;
+
+```
+
+Use:
+```
+
+typedef myclass< some\_symbol>
+              mytypedef;
+
+```
+
+Where `some_symbol` is the symbolic name of a an
+ integral constant expression whose value is
+ `(INTEGRAL_CONSTANT1 == INTEGRAL_CONSTANT2).`
+
+
+Rationale: the older EDG based compilers (some of which are
+ used in the most recent version of that platform's compiler),
+ don't recognise expressions containing operators as non-type
+ template parameters, even though such expressions can be used
+ as integral constant expressions elsewhere.
+
+
+### Always use a fully qualified name to refer to an integral
+ constant expression.
+
+
+For example:
+```
+
+typedef myclass< ::boost::is\_integral<some\_type>::value> mytypedef;
+
+```
+
+Rationale: at least one compiler (Borland's), doesn't
+ recognise the name of a constant as an integral constant
+ expression unless the name is fully qualified (which is to say
+ it starts with `::`).
+
+
+### Always leave a space after a '`<`' and before
+ '`::`'
+
+
+For example:
+```
+
+typedef myclass< ::boost::is\_integral<some\_type>::value> mytypedef;
+                ^
+                ensure there is space here!
+
+```
+
+Rationale: `<:` is a legal digraph in it's own
+ right, so `<::` is interpreted as the same as
+ `[:`.
+
+
+### Don't use local names as integral constant expressions
+
+
+Example:
+```
+
+template <class T>
+struct foobar
+{
+   BOOST\_STATIC\_CONSTANT(int, temp = computed\_value);
+   typedef myclass<temp> mytypedef;  // error
+};
+
+```
+
+Rationale: At least one compiler (Borland's) doesn't accept
+ this.
+
+
+Although it is possible to fix this by using:
+```
+
+template <class T>
+struct foobar
+{
+   BOOST\_STATIC\_CONSTANT(int, temp = computed\_value);
+   typedef foobar self\_type;
+   typedef myclass<(self\_type::temp)> mytypedef;  // OK
+};
+
+```
+
+This breaks at least one other compiler (VC6), it is better
+ to move the integral constant expression computation out into a
+ separate traits class:
+```
+
+template <class T>
+struct foobar\_helper
+{
+   BOOST\_STATIC\_CONSTANT(int, value = computed\_value);
+};
+
+template <class T>
+struct foobar
+{
+   typedef myclass< ::foobar\_helper<T>::value> mytypedef;  // OK
+};
+
+```
+
+### Don't use dependent default parameters for non-type
+ template parameters.
+
+
+For example:
+```
+
+template <class T, int I = ::boost::is\_integral<T>::value>  // Error can't deduce value of I in some cases.
+struct foobar;
+
+```
+
+Rationale: this kind of usage fails for Borland C++. Note
+ that this is only an issue where the default value is dependent
+ upon a previous template parameter, for example the following
+ is fine:
+```
+
+template <class T, int I = 3>  // OK, default value is not dependent
+struct foobar;
+
+```
+
+Unresolved Issues
+-----------------
+
+
+The following issues are either unresolved or have fixes
+ that are compiler specific, and/or break one or more of the
+ coding guidelines.
+
+
+### Be careful of numeric\_limits
+
+
+There are three issues here:
+
+
+1. The header <limits> may be absent - it is
+ recommended that you never include <limits> directly
+ but use <boost/pending/limits.hpp> instead. This header
+ includes the "real" <limits> header if it is available,
+ otherwise it supplies it's own std::numeric\_limits
+ definition. Boost also defines the macro BOOST\_NO\_LIMITS if
+ <limits> is absent.
+2. The implementation of std::numeric\_limits may be defined
+ in such a way that its static-const members may not be usable
+ as integral constant expressions. This contradicts the
+ standard but seems to be a bug that affects at least two
+ standard library vendors; boost defines
+ BOOST\_NO\_LIMITS\_COMPILE\_TIME\_CONSTANTS in
+ <boost/config.hpp> when this is the case.
+3. There is a strange bug in VC6, where the members of
+ std::numeric\_limits can be "prematurely evaluated" in
+ template code, for example:
+```
+
+template <class T>
+struct limits\_test
+{
+   BOOST\_STATIC\_ASSERT(::std::numeric\_limits<T>::is\_specialized);
+};
+
+```
+
+This code fails to compile with VC6 even though no instances
+ of the template are ever created; for some bizarre reason
+ `::std::numeric_limits<T>::is_specialized`
+ always evaluates to false, irrespective of what the template
+ parameter T is. The problem seems to be confined to expressions
+ which depend on std::numeric\_limts: for example if you replace
+ `::std::numeric_limits<T>::is_specialized`
+ with `::boost::is_arithmetic<T>::value`, then
+ everything is fine. The following workaround also works but
+ conflicts with the coding guidelines:
+```
+
+template <class T>
+struct limits\_test
+{
+   BOOST\_STATIC\_CONSTANT(bool, check = ::std::numeric\_limits<T>::is\_specialized);
+   BOOST\_STATIC\_ASSERT(check);
+};
+
+```
+
+So it is probably best to resort to something like this:
+```
+
+template <class T>
+struct limits\_test
+{
+#ifdef BOOST\_MSVC
+   BOOST\_STATIC\_CONSTANT(bool, check = ::std::numeric\_limits<T>::is\_specialized);
+   BOOST\_STATIC\_ASSERT(check);
+#else
+   BOOST\_STATIC\_ASSERT(::std::numeric\_limits<T>::is\_specialized);
+#endif
+};
+
+```
+
+### Be careful how you use the sizeof operator
+
+
+As far as I can tell, all compilers treat sizeof expressions
+ correctly when the argument is the name of a type (or a
+ template-id), however problems can occur if:
+
+
+1. The argument is the name of a member-variable, or a local
+ variable (code may not compile with VC6).
+2. The argument is an expression which involves the creation
+ of a temporary (code will not compile with Borland C++).
+3. The argument is an expression involving an overloaded
+ function call (code compiles but the result is a garbage
+ value with Metroworks C++).
+
+
+### Don't use boost::is\_convertible unless you have to
+
+
+Since is\_convertible is implemented in terms of the sizeof
+ operator, it consistently gives the wrong value when used with
+ the Metroworks compiler, and may not compile with the Borland's
+ compiler (depending upon the template arguments used).
+
+
+
+
+
+
+
+
+

development/library_metadata.html

@@ -0,0 +1,212 @@
+---
+title: Library Metadata - Boost C++ Libraries
+copyright: Beman Dawes, David Abrahams, 1998-2005. Rene Rivera 2004-2005.
+revised: 2005-12-17 14:32:46 -0500
+---
+
+
+Library Metadata - Boost C++ Libraries
+
+
+
+Library Metadata
+================
+
+A module can contain an optional file which describes the
+ libraries that it contains. This is located at
+ `meta/libraries.json`. It either contains a single
+ json object for a single library, or a list or json objects for
+ any number of libraries.
+
+
+For example, for a single library:
+```
+
+{
+    "key": "unordered",
+    "name": "Unordered",
+    "authors": [ "Daniel James" ],
+    "maintainers": [ "Daniel James <dnljms -at- gmail.com>" ],
+    "description": "Unordered associative containers.",
+    "category": [
+        "Containers"
+    ]
+}
+
+
+```
+
+An example for multiple libraries:
+```
+
+[
+    {
+        "key": "functional",
+        "name": "Functional",
+        "authors": [ "Mark Rodgers" ],
+        "description": "The Boost.Function library contains a family of class templates that are function object wrappers.",
+        "category": [
+            "Function-objects"
+        ]
+    },
+    {
+        "key": "functional/factory",
+        "name": "Functional/Factory",
+        "authors": [ "Tobias Schwinger" ],
+        "maintainers": [ "Tobias Schwinger <tschwinger -at- isonews2.com>" ],
+        "description": "Function object templates for dynamic and static object creation",
+        "documentation": "factory/",
+        "category": [
+            "Function-objects"
+        ]
+    },
+]
+
+
+```
+
+Json fields
+-----------
+
+
+### key
+
+
+This is a unique identifier for the library, typically the
+ path to it from the `libs` directory.
+
+
+### name
+
+
+Human readable name of the library
+
+
+### status
+
+
+Used for libraries with special statuses, currently can have
+ value `deprecated` for deprecated libraries, and
+ `hidden` for libraries which shouldn't be displayed to
+ the user.
+
+
+### authors
+
+
+Either a string, or a list of strings, containing the names
+ of the authors
+
+
+### description
+
+
+A brief description of what the library does
+
+
+### category
+
+
+A list of categories that the library belongs to, the full
+ list is below.
+
+
+### documentation
+
+
+Path to the documentation, defaults to the root of the
+ module.
+
+
+### cxxstd
+
+
+The minimum C++ standard compilation level at which
+ all, or the large majority, of the functionality in
+ the library is usable. The possible values are: 
+
+
+* 98 = C++98
+* 03 = C++98/C++03
+* 11 = C++11
+* 14 = C++14
+* 17 = C++17
+* 20 = C++20
+
+
+The level only indicates the minimum level, which
+ means that the functionality of the library can be
+ used when compiling at that level or at a higher
+ level. There may be some functionality in the library
+ which will need a higher C++ standard compilation
+ level than is indicated by this value, but the
+ information about that specific functionality will be
+ provided for the end-user within the documentation for
+ that library. If a library does not have this field it
+ indicates that the end-user will have to read the
+ library documentation to understand what C++ standard
+ compilation level is needed to use the library. 
+
+
+Available categories
+--------------------
+String
+String and text processing
+Containers
+Containers
+Iterators
+Iterators
+Algorithms
+Algorithms
+Function-objects
+Function objects and higher-order programming
+Generic
+Generic Programming
+Metaprogramming
+Template Metaprogramming
+Preprocessor
+Preprocessor Metaprogramming
+Concurrent
+Concurrent Programming
+Math
+Math and numerics
+Correctness
+Correctness and testing
+Error-handling
+Error handling and recovery
+Data
+Data structures
+Domain
+Domain Specific
+Image-processing
+Image processing
+IO
+Input/Output
+Inter-language
+Inter-language support
+Emulation
+Language Features Emulation
+Memory
+Memory
+Parsing
+Parsing
+Patterns
+Patterns and Idioms
+Programming
+Programming Interfaces
+State
+State Machines
+System
+System
+Miscellaneous
+Miscellaneous
+workarounds
+Broken compiler workarounds
+
+
+
+
+
+
+
+

development/report-apr-2006.html

@@ -0,0 +1,257 @@
+---
+title: Review Wizard Status Report for April 2006
+copyright: 
+revised: 
+---
+
+
+Review Wizard Status Report for April 2006
+
+
+
+Review Wizard Status Report for April 2006
+==========================================
+
+News
+----
+
+
+April 1, 2006 -- The "Promotion Traits" Review Begins
+ (Fast-Track) Proposal to add promote, integral\_promotion and
+ floating\_point\_promotion class templates to type\_traits
+ library.
+
+
+April 6, 2006 -- The "Function Types" Review Begins
+ (Fast-Track) This library provides a metaprogramming facility
+ to classify, decompose and synthesize function-, function
+ pointer-, function reference- and member function pointer
+ types.
+
+
+March 22, 2006 -- Asio Accepted Announcement: <https://lists.boost.org/Archives/boost/2006/03/102287.php>
+
+
+February 17, 2006 - Shared Memory Library Accepted
+ Announcement: <https://lists.boost.org/boost-announce/2006/02/0083.php>
+
+
+February 5, 2006 - Fixed String Library Rejected
+ Announcement: <https://lists.boost.org/boost-announce/2006/02/0081.php>
+
+
+We need experienced review managers. Please take a look at
+ the list of libraries in need of managers and check out their
+ descriptions. If you can serve as review manager for any of
+ them, email Ron Garcia or Tom Brinkman "garcia at cs dot
+ indiana dot edu" and "reportbase at gmail dot com"
+ 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 Tom.
+
+
+If you're library author and plan on submitting a library
+ for review in the next 3-6 months, send Ron or Tom a short
+ description of your library and we'll add it to the Libraries
+ Under Construction below. We know that there are many libaries
+ that are near completion, but we have hard time keeping track
+ all of them. Please keep us informed about your progress.
+
+
+Review
+ Queue
+-------------
+
+
+* Promotion Traits - April 1, 2006 (fast-track)
+* Function Types - April 6, 2006 (fast-track)
+* Fusion
+* Pimpl Pointer
+* Property Tree
+* Physical Quantities System
+* Intrusive Containers
+
+---
+
+
+### Function Types
+ (mini-re-review)
+
+
+| Author: | Tobias Schwinger |
+| Review Manager: | Tom Brinkman |
+| Download: | <http://boost-sandbox.sourceforge.net/vault/> |
+| Description: | This library provides a
+ metaprogramming facility to classify, decompose and
+ synthesize function-, function pointer-, function
+ reference- and member function pointer types. For the
+ purpose of this documentation, these types are
+ collectively referred to as function types (this
+ differs from the standard definition and redefines the
+ term from a programmer's perspective to refer to the
+ most common types that involve functions).
+The classes introduced by this library shall conform
+ to the concepts of the Boost Metaprogramming library
+ (MPL).
+
+The Function Types library enables the user
+ to:
+
+* test an arbitrary type for being a function
+ type of specified kind,
+* inspect properties of function types,
+* view and modify sub types of an encapsulated
+ function type with MPL Sequence operations,
+ and
+* synthesize function types.
+
+This library supports variadic
+ functions and can be configured to support non-default
+ calling conventions. |
+
+
+### Promotion Traits
+
+
+| Author: | Alexander Nasonov |
+| Review Manager: | Tobias Schwinger |
+| Download: | <http://cpp-experiment.sourceforge.net/promote-20050917.tar.gz> |
+| Description: | Proposal to add promote,
+ integral\_promotion and floating\_point\_promotion class
+ templates to type\_traits library.
+Alexander tried it on different compilers with
+ various success: GNU/Linux (gentoo-hardened): gcc 3.3
+ and 3.4, Intel 7, 8 and 9 Windows: VC7 free compiler
+ Sparc Solaris: Sun C++ 5.3 and 5.7
+See comments at the beginning of
+ promote\_enum\_test.cpp for what is broken. |
+
+
+### Intrusive Containers
+
+
+| Author: | Olaf Krzikalla |
+| Review Manager: | Thorsten Ottosen |
+| Download: | <http://people.freenet.de/turtle++/intrusive.zip> |
+| Description: | While intrusive containers were
+ and are widely used in C, they became more and more
+ forgotten in the C++-world due to the presence of the
+ standard containers, which don't support intrusive
+ techniques. Boost.Intrusive not only reintroduces this
+ technique to C++, but also encapsulates the
+ implementation in STL-like interfaces. Hence anyone
+ familiar with standard containers can use intrusive
+ containers with ease. |
+
+
+### Fusion
+
+
+| Author: | Joel de Guzman |
+| Review Manager: | Ron Garcia |
+| Download: | <http://spirit.sourceforge.net/dl_more/fusion_v2/>
+<http://spirit.sourceforge.net/dl_more/fusion_v2.zip> |
+| Description: | Fusion is a library of heterogenous
+ containers and views and algorithms. A set of
+ heterogenous containers (vector, list, set and map) is
+ provided out of the box along with view classes that
+ present various composable views over the data. The
+ containers and views follow a common sequence concept
+ with an underlying iterator concept that binds it all
+ together, suitably making the algorithms fully generic
+ over all sequence types.
+The architecture is somewhat modeled
+ after MPL which in turn is modeled after STL. It is
+ code-named "fusion" because the library is the "fusion"
+ of compile time metaprogramming with runtime
+ programming. |
+
+
+### Pimpl
+ Pointer
+
+
+| Author: | Asger Mangaard |
+| Review Manager: | Need Volunteer |
+| Download: | Boost Sandbox (<http://boost-consulting.com/vault/>)
+ under pimpl\_ptr. |
+| Description: | The pimpl idiom is widely used to
+ reduce compile times and disable code coupling. It does
+ so by moving private parts of a class from the .hpp file
+ to the .cpp file. However, it's implementation can be
+ tricky, and with many pitfalls (especially regarding
+ memory management). The pimpl\_ptr library is a single
+ header file, implementing a special policy based smart
+ pointer to greately ease the implementation of the pimpl
+ idiom. |
+
+
+### Property
+ Tree
+
+
+| Author: | Marcin Kalicinski |
+| Review Manager: | Need Volunteer |
+| Download: | Boost Sandbox Vault -
+ property\_tree\_rev4.zip <http://kaalus.atspace.com/ptree> |
+| Description: | Property tree is a data structure
+ - a tree of (key, value) pairs. It differs from its
+ cousin, "usual" property map, because it is hierarchical,
+ not linear. Thus, it is more like a minimalistic Document
+ Object Model, but not bound to any specific file format.
+ It can store contents of XML files, windows registry,
+ JSON files, INI files, even command line parameters. The
+ library contains parsers for all these formats, and
+ more. |
+
+
+### Physical Quantities
+ System
+
+
+| Author: | Andy Little |
+| Review Manager: | Need Volunteer |
+| Download: | <http://tinyurl.com/7m5l8> |
+| Description: | PQS (Physical Quantities System)
+ is used for modelling physical-quantities in C++
+ programs. The advantages over using built-in types in the
+ role include: trapping errors in dimensional analysis,
+ detailed semantic specifications for reliable and
+ repeatable conversions between units and
+ self-documentation of source code. PQS is based around
+ the principles and guidelines of the International System
+ of Units (SI). The library predefines a large number of
+ quantities, physical and maths constants using a common
+ syntax. The library also includes (or will soon include)
+ classes for manipulating quantities algebraically, for
+ example angles (radians, steradians,
+ degrees,minutes,seconds) and vectors, matrices and
+ quaternions for more advanced modelling of physical
+ systems. |
+
+
+Libraries under
+ development
+----------------------------
+
+
+Geometry Library - Author - Andy Little (?)
+
+
+C2\_functions Library - Author - Marcus Mendenhall
+
+
+Please let us know of any libraries you are currently
+ developing that you intend to submit for review.
+
+
+
+
+
+
+
+
+

development/report-dec-2009.html

@@ -0,0 +1,565 @@
+---
+title: Review Wizard Status Report for December 2009
+copyright: 
+revised: 
+---
+
+
+Review Wizard Status Report for December 2009
+
+
+
+Review Wizard Status Report for December 2009
+=============================================
+
+News
+----
+
+
+Polygon Library Accepted
+Boost 1.40 Released
+New Libraries: None
+Revised Libraries: Accumulators, Asio, Circular Buffer, Filesystem, Foreach, Function, Fusion, Hash, Interprocess, Intrusive, MPL, Program Options, Proto, Python, Serialization, Unordered, Xpressive
+
+Geometry Library Accepted
+Boost 1.41 Released
+New Libraries: Property Tree
+Revised Libraries: DateTime, Filesystem, Iostreams, Math, Multi-index Containers, Proto, Python, Regex, Spirit, System, Thread, Unordered, Utility, Wave, Xpressive
+
+MSM Library Review Underway
+
+
+Constrained Value Review - Review Result still Pending
+
+Older Issues
+============
+
+
+The Time Series Library, accepted in August 2007, has not yet been
+submitted to SVN.
+
+
+The Floating Point Utilities Library, has not yet been submitted to
+SVN. It is slated to be integrated with the Boost.Math library.
+
+
+The Switch Library, accepted provisionally in January 2008,
+has not yet been submitted for mini-review and full acceptance.
+
+
+The Phoenix Library, accepted provisionally in September 2008,
+has not yet been submitted for mini-review and full acceptance.
+
+
+For libraries that are still waiting to get into SVN, please get them
+ready and into the repository. The developers did some great work
+making the libraries, so don't miss the chance to share that work with
+others.
+
+General Announcements
+=====================
+
+
+As always, we need experienced review managers. The review queue has
+been growing substantially but we have had few volunteers, so manage
+reviews if possible and if not please make sure to watch the review
+schedule and participate. 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 osl dot iu dot edu"
+and "phillips at mps dot ohio-state dot edu" respectively.
+
+
+We are also suffering from a lack of reviewers. While we all
+understand time pressures and the need to complete paying work, the
+strength of Boost is based on the detailed and informed reviews
+submitted by you. A recent effort is trying to secure at least five
+people who promise to submit reviews as a precondition to starting
+the review period. Consider volunteering for this and even taking the
+time to create the review as early as possible. No rule says you can
+only work on a review during the review period.
+
+
+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 a 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.
+
+
+The included review queue isn't a classic queue. It is more an unordered list of the libraries awaiting review. As such, any library in the queue can be reviewed once the developer is ready and a review manager works with the wizards and the developer to schedule a review. It is not FIFO.
+
+Review Queue
+============
+
+
+* Lexer
+* Shifted Pointer
+* Logging
+* Log
+* Join
+* Pimpl
+* Task
+* Endian
+* Conversion
+* Sorting
+* GIL.IO
+* AutoBuffer
+* String Convert
+* Move
+* Containers
+* Interval Containers
+* Type Traits Extensions
+* Interthreads
+* Bitfield
+* Lockfree
+
+---
+Lexer
+-----
+
+
+| Author: | Ben Hanson |
+| Review Manager: | Eric Neibler |
+| Download: | [Boost Vault](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. |
+
+Shifted Pointer
+---------------
+
+
+| Author: | Phil Bouchard |
+| Review Manager: | Needed |
+| Download: | [Boost Vault](http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directory=Memory) |
+| Description: | Smart pointers are in general optimized for a specific resource
+(memory usage, CPU cycles, user friendliness, ...) depending on
+what the user need to make the most of. The purpose of this smart
+pointer is mainly to allocate the reference counter (or owner) and
+the object itself at the same time so that dynamic memory management
+is simplified thus accelerated and cheaper on the memory map. |
+
+Logging
+-------
+
+
+| Author: | John Torjo |
+| Review Manager: | Gennadiy Rozental |
+| 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! |
+
+Log
+---
+
+
+| Author: | Andrey Semashev |
+| Review Manager: | Needed |
+| Download: | [Boost Vault](http://tinyurl.com/cm9lum) |
+| Description: | The library is aimed to help adding logging features to
+applications. It provides out-of-box support for many widely used
+capabilities, such as formatting and filtering based on attributes,
+sending logs to a syslog server or to Windows Event Log, or simply
+storing logs into files. It also provides basic support for the
+library initialization from a settings file. The library can also be
+used for a wider range of tasks and implement gathering and processing
+statistical information or notifying user about application events. |
+
+Join
+----
+
+
+| Author: | Yigong Liu |
+| Review Manager: | Needed |
+| Download: | <http://channel.sourceforge.net/> |
+| Description: | Join is an asynchronous, message based C++ concurrency
+library based on join calculus. It is applicable both to
+multi-threaded applications and to the orchestration of asynchronous,
+event-based applications. It follows Comega's design and
+implementation and builds with Boost facilities. It provides a high
+level concurrency API with asynchronous methods, synchronous methods,
+and chords which are "join-patterns" defining the synchronization,
+asynchrony, and concurrency. |
+
+Pimpl
+-----
+
+
+| Author: | Vladimir Batov |
+| Review Manager: | Needed |
+| Download: | 
+[Boost Vault](http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=Pimpl.zip&directory=&)
+<http://www.ddj.com/cpp/205918714> (documentation)
+ |
+| Description: | The Pimpl idiom is a simple yet robust technique to
+minimize coupling via the separation of interface and implementation
+and then implementation hiding. This library provides a convenient
+yet flexible and generic deployment technique for the Pimpl idiom.
+It's seemingly complete and broadly applicable, yet minimal, simple
+and pleasant to use. |
+
+Task
+----
+
+
+| Author: | Oliver Kowalke |
+| Review Manager: | Needed |
+| Download: | [Boost Vault](http://www.boostpro.com/vault/index.php?action=downloadfile&amp;filename=boost-threadpool.2.tar.gz&amp;directory=Concurrent%20Programming) |
+| Description: | Formerly called Thread Pool
+The library provides:
+\* thread creation policies:
+
+* determines the management of worker threads:
+* fixed set of threads in pool
+* create workerthreads on demand (depending on context)
+* let worker threads ime out after certain idle time
+
+
+* channel policies: manages access to queued tasks:
+
+	+ bounded channel with high and low watermark for queuing tasks
+	+ unbounded channel with unlimited number of queued tasks
+	+ rendezvous syncron hand-over between producer and consumer threads
+* queueing policy: determines how tasks will be removed from channel:
+
+	+ FIFO
+	+ LIFO
+	+ priority queue (attribute assigned to task)
+	+ smart insertions and extractions (for instance remove oldest task with
+	certain attribute by newest one)
+* tasks can be chained and lazy submit of taks is also supported (thanks to
+Braddocks future library).
+* returns a task object from the submit function. The task it self can
+be interrupted if its is cooperative (means it has some interruption points
+in its code -> this\_thread::interruption\_point() ).
+ |
+
+Endian
+------
+
+
+| Author: | Beman Dawes |
+| Review Manager: | Needed |
+| Download: | <http://mysite.verizon.net/beman/endian-0.10.zip> |
+| Description: |  |
+
+Conversion
+----------
+
+
+| Author: | Vicente Botet |
+| Review Manager: | Needed |
+| Download: | [Boost Vault](http://www.boostpro.com/vault/index.php?action=downloadfile&amp;filename=conversion.zip&amp;directory=Utilities&amp;) |
+| Description: | Generic explicit conversion between unrelated types.
+
+Boost.Conversion provides:
+* a generic convert\_to function which can be specialized by the user to
+make explicit conversion between unrelated types.
+* a generic assign\_to function which can be specialized by the user to
+make explicit assignation between unrelated types.
+* conversion between std::complex of explicitly convertible types.
+* conversion between std::pair of explicitly convertible types.
+* conversion between boost::optional of explicitly convertible types.
+* conversion between boost::rational of explicitly convertible types.
+* conversion between boost::interval of explicitly convertible types.
+* conversion between boost::chrono::time\_point and boost::ptime.
+* conversion between boost::chrono::duration and boost::time\_duration.
+ |
+
+Sorting
+-------
+
+
+| Author: | Steven Ross |
+| Review Manager: | Needed |
+| Download: | [Boost Vault](http://www.boostpro.com/vault/index.php?action=downloadfile&amp;filename=algorithm_sorting.zip) |
+| Description: | A grouping of 3 templated hybrid radix/comparison-based sorting
+algorithms that provide superior worst-case and average-case
+performance to std::sort: integer\_sort, which sorts fixed-size data
+types that support a rightshift (default of >>) and a comparison
+(default of <) operator. float\_sort, which sorts standard
+floating-point numbers by safely casting them to integers.
+string\_sort, which sorts variable-length data types, and is optimized
+for 8-bit character strings.
+All 3 algorithms have O(n(k/s + s)) runtime where k is the number of
+bits in the data type and s is a constant, and limited memory overhead
+(in the kB for realistic inputs). In testing, integer\_sort varies
+from 35% faster to 8X as fast as std::sort, depending on processor,
+compiler optimizations, and data distribution. float\_sort is roughly
+7X as fast as std::sort on x86 processors. string\_sort is roughly 2X
+as fast as std::sort. |
+
+GIL.IO
+------
+
+
+| Author: | Christian Henning |
+| Review Manager: | Needed |
+| Download: | [GIL Google Code Vault](http://gil-contributions.googlecode.com/files/rc2.zip) |
+| Description: | I/O extension for boost::gil which allows reading and
+writing of/in various image formats ( tiff, jpeg, png, etc ). This
+review will also include the Toolbox extension which adds some common
+functionality to gil, such as new color spaces, algorithms, etc. |
+
+AutoBuffer
+----------
+
+
+| Author: | Thorsten Ottosen |
+| Review Manager: | Needed |
+| Download: | [Here](http://www.cs.aau.dk/~nesotto/boost/auto_buffer.zip) |
+| Description: | Boost.AutoBuffer provides a container for efficient dynamic, local buffers.
+Furthermore, the container may be used as an alternative to std::vector,
+offering greater flexibility and sometimes better performance. |
+
+String Convert
+--------------
+
+
+| Author: | Vladimir Batov |
+| Review Manager: | Needed |
+| Download: | [Boost Vault](http://www.boostpro.com/vault/index.php?action=downloadfile&amp;filename=boost-string-convert.zip) |
+| Description: | The library takes the approach of boost::lexical\_cast in the area of
+string-to-type and type-to-string conversions, builds on the past
+boost::lexical\_cast experience and advances that conversion
+functionality further to additionally provide:
+
+* throwing and non-throwing conversion-failure behavior;
+* support for the default value to be returned when conversion fails;
+* two types of the conversion-failure check -- basic and better/safe;
+* formatting support based on the standard I/O Streams and the standard
+(or user-defined) I/O Stream-based manipulators
+(like std::hex, std::scientific, etc.);
+* locale support;
+* support for boost::range-compliant char and wchar\_t-based string containers;
+* no DefaultConstructibility requirement for the Target type;
+* consistent framework to uniformly incorporate any type-to-type conversions.
+It is an essential tool with applications making extensive use of
+configuration files or having to process/prepare considerable amounts
+of data in, say, XML, etc. |
+
+Move
+----
+
+
+| Author: | Ion Gaztanaga |
+| Review Manager: | Needed |
+| Download: | <http://svn.boost.org/svn/boost/sandbox/move/> and online documentation at <http://svn.boost.org/svn/boost/sandbox/move/libs/move/doc/html/index.html> |
+| Description: | In C++0x, move semantics are implemented with the introduction of
+rvalue references. They allow us to implement move() without verbosity
+or runtime overhead. Boost.Move is a library that offers tools to
+implement those move semantics not only in compilers with rvalue
+references but also in compilers conforming to C++03. |
+
+Containers
+----------
+
+
+| Author: | Ion Gaztanaga |
+| Review Manager: | Needed |
+| Download: | <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost.move.container>.zip&directory=Containers& |
+| Documentation: | <http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.html> |
+| Description: | Boost.Container library implements several well-known containers,
+including STL containers. The aim of the library is to offers advanced
+features not present in standard containers or to offer the latest
+standard draft features for compilers that comply with C++03. |
+
+Interval Containers Library
+---------------------------
+
+
+| Author: | Joachim Faulhaber |
+| Download: | <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_3_2_0.zip&directory=Containers> |
+| Documentation: | <http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/index.html> |
+| Review Manager: | Needed |
+| Description: | The Interval Template Library (Itl) provides intervals
+and two kinds of interval containers: Interval\_sets and
+interval\_maps. Interval\_sets and maps can be used just
+as sets or maps of elements. Yet they are much more
+space and time efficient when the elements occur in
+contiguous chunks: intervals. This is obviously the case
+in many problem domains, particularly in fields that deal
+with problems related to date and time.
+Interval containers allow for intersection with interval\_sets
+to work with segmentation. For instance you might want
+to intersect an interval container with a grid of months
+and then iterate over those months.
+Finally interval\_maps provide aggregation on
+associated values, if added intervals overlap with
+intervals that are stored in the interval\_map. This
+feature is called aggregate on overlap. It is shown by
+example:
+
+```
+
+typedef set<string> guests;
+interval\_map<time, guests> party;
+guests mary; mary.insert("Mary");
+guests harry; harry.insert("Harry");
+party += make\_pair(interval<time>::rightopen(20:00, 22:00),mary);
+party += make\_pair(interval<time>::rightopen\_(21:00, 23:00),harry);
+// party now contains
+[20:00, 21:00)->{"Mary"}
+[21:00, 22:00)->{"Harry","Mary"} //guest sets aggregated on overlap
+[22:00, 23:00)->{"Harry"}
+
+```
+
+As can be seen from the example an interval\_map has both
+a decompositional behavior (on the time dimension) as well as
+a accumulative one (on the associated values). |
+
+Type Traits Extensions
+----------------------
+
+
+| Author: | Frederic Bron |
+| Review Manager: | Needed |
+| Download: | <http://svn.boost.org/trac/boost/browser/sandbox/type_traits> |
+| Description: | The purpose of the addition is to add type traits to detect if types T and U
+are comparable in the sense of <, <=, >, >=, == or != operators, i.e. if
+t<u has a sens when t is of type T and u of type U (same for <=, >, >=, ==,
+!=).
+The following traits are added:
+is\_equal\_to\_comparable<T,U>
+is\_greater\_comparable<T,U>
+is\_greater\_equal\_comparable<T,U>
+is\_less\_comparable<T,U>
+is\_less\_equal\_comparable<T,U>
+is\_not\_equal\_to\_comparable<T,U>
+The names are based on the corresponding names of the standard
+template library (<functional> header, section 20.3.3 of the
+standard).
+The code has the following properties:
+\* returns true if t<u is meaningful and returns a value convertible to bool
+\* returns false if t<u is meaningless.
+\* fails with compile time error if t<u is meaningful and returns void
+(a possibility to avoid compile time error would be to return true
+with an operator, trick but this has little sens as returning false
+would be better) |
+
+InterThreads
+------------
+
+
+| Author: | Vicente J. Botet Escriba |
+| Review Manager: | Needed |
+| Download: | [Boost Vault](http://www.boostpro.com/vault/index.php?action=downloadfile&amp;filename=interthreads.zip&amp;directory=Concurrent%20Programming&amp;) |
+| Description: | 
+Boost.InterThreads extends Boost.Threads adding some features:
+* thread decorator: thread\_decorator allows to define
+setup/cleanup functions which will be called only once by
+thread: setup before the thread function and cleanup at thread
+exit.
+* thread specific shared pointer: this is an extension of the
+thread\_specific\_ptr providing access to this thread specific
+context from other threads. As it is shared the stored pointer
+is a shared\_ptr instead of a raw one.
+* thread keep alive mechanism: this mechanism allows to detect
+threads that do not prove that they are alive by calling to the
+keep\_alive\_point regularly. When a thread is declared dead a
+user provided function is called, which by default will abort
+the program.
+* thread tuple: defines a thread groupe where the number of
+threads is know statically and the threads are created at
+construction time.
+* set\_once: a synchonizer that allows to set a variable only once,
+notifying to the variable value to whatever is waiting for that.
+* thread\_tuple\_once: an extension of the boost::thread\_tuple which
+allows to join the thread finishing the first, using for that
+the set\_once synchronizer.
+* thread\_group\_once: an extension of the boost::thread\_group which
+allows to join the thread finishing the first, using for that
+the set\_once synchronizer.
+
+(thread\_decorator and thread\_specific\_shared\_ptr) are based on the
+original implementation of threadalert written by Roland Schwarz.
+Boost.InterThreads extends Boost.Threads adding thread setup/cleanup
+decorator, thread specific shared pointer, thread keep alive
+mechanism and thread tuples. |
+
+Bitfield
+--------
+
+
+| Author: | Vicente J. Botet Escriba |
+| Review Manager: | Needed |
+| Download: | <http://svn.boost.org/svn/boost/sandbox/bitfield> with documentation available at <http://svn.boost.org/svn/boost/sandbox/bitfield/libs/integer/doc/index.html> |
+| Description: | 
+Portable bitfields traits. Boost.Bitfield consists of:
+* a generic bitfield traits class providing generic getter and setter methods.
+* a BOOST\_BITFIELD\_DCL macro making easier the definition of the bitfield traits and the bitfield getter and setter functions.
+ |
+
+Lockfree
+--------
+
+
+| Author: | Tim Blechmann |
+| Review Manager: | Needed |
+| Download: | <http://www.boostpro.com/vault/index.php?action=downloadfile&amp;filename=boost_lockfree-241109.zip&amp;directory=Concurrent%20Programming&amp>; |
+| Documentation: | <http://tim.klingt.org/boost_lockfree/> |
+| Description: | boost.lockfree provides implementations of lock-free data structures.
+lock-free data structures can be accessed by multiple threads without
+the necessity of blocking synchronization primitives such as guards.
+lock-free data structures can be used in real-time systems, where
+blocking algorithms may lead to high worst-case execution times, to
+avoid priority inversion, or to increase the scalability for
+multi-processor machines.
+
+boost.lockfree provides:
+* boost::lockfree::fifo, a lock-free fifo queue
+* boost::lockfree::stack, a lock-free stack
+the code is available from from my personal git repository:
+* git://tim.klingt.org/boost\_lockfree.git
+* <http://tim.klingt.org/git?p=boost_lockfree.git>
+ |
+
+
+Libraries under development
+===========================
+Persistent
+----------
+
+
+| Author: | Tim Blechmann |
+| Description: | A library, based on Boost.Serialization, that provides access to persistent
+objects with an interface as close as possible to accessing regular objects
+in memory.* object ownership concepts equivalent to the ones used by Boost.SmartPtr:
+shared, weak, scoped (and raw)
+* ACID transactions, including recovery after a crash and "Serializable"
+isolation level
+* concurrent transactions, nested transactions, distributed transactions
+* concurrent access containers: STL containers whose nodes are implemented as
+persistent objects and can be accessed without moving the container to
+memory. Concurrent transactions modifying the container are only repeated in
+the rare cases the same container node is changed simultanisouly by 2
+threads.
+* extensible by other transactional resources, e.g. an object relational
+mapper based on the upcoming Boost.Rdb library. Multiple resources can be
+combined to one database, with distributed transactions among them.
+
+Please let us know of any libraries you are currently
+developing that you intend to submit for review. |
+
+
+See <http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction>
+for a current listing of libraries under development.
+

development/report-jan-2006.html

@@ -0,0 +1,262 @@
+---
+title: Review Wizard Status Report for January 2006
+copyright: 
+revised: 
+---
+
+
+Review Wizard Status Report for January 2006
+
+
+
+Review Wizard Status Report for January 2006
+============================================
+
+News
+----
+
+
+Happy New Year! Here are some statistics regarding Boost
+ Library reviews in 2005:
+
+
+* 12 Libraries were reviewed
+* 8 Libraries were accepted
+* 1 Library (Function Types) was accepted pending a
+ mini-review
+* 2 Libraries were rejected
+* 1 Library has yet to receive a final verdict (ASIO)
+
+
+Policy Pointer has been removed from the review queue
+ because the author has stated that it is not quite ready.
+
+
+We need review managers. Please take a look at the list of
+ libraries in need of managers and check out their descriptions.
+ If you can serve as review manager for any of them, send one of
+ us an email.
+Note:
+If you have any suggestions about how we could improve
+ the Review Wizard's status report, please email "reportbase
+ at gmail dot com" and "garcia at cs dot indiana dot
+ edu".
+
+Review Managers Needed
+----------------------
+
+
+There are a few libraries in the review queue in need of
+ review managers. If you would like to volunteer to be a review
+ manager, please contact Ron or Tom.
+
+
+The following libraries still require review managers:
+
+
+* Fusion
+* Shmem
+* Pimpl Pointer
+* Type Traits (modification)
+* Function Types
+
+
+Review
+ Queue
+-------------
+
+
+* Fixed Strings - January 19 2006 - January 28 2006
+* Intrusive Containers
+* Function Types (mini-re-review)
+* Shmem
+* Fusion
+* Pimpl Pointer
+* Type Traits (modification)
+
+---
+
+
+### Fixed
+ Strings
+
+
+| Author: | Reece Dunn |
+| Review Manager: | Harmut Kaiser |
+| Download: | Boost Sandbox (<http://boost-sandbox.sourceforge.net/>)
+ under fixed\_string |
+| Description: | The fixed string library provides
+ buffer overrun protection for static sized strings (char
+ s[ n ]). It provides a C-style string interface for
+ compatibility with C code (for example, porting a C
+ program to C++). There is also a std::string-style
+ interface using a class based on flex\_string by Andre
+ Alexandrescu with a few limitations due to the
+ non-resizable nature of the class. |
+
+
+### Intrusive Containers
+
+
+| Author: | Olaf Krzikalla |
+| Review Manager: | to be determined |
+| Download: | <http://people.freenet.de/turtle++/intrusive.zip> |
+| Description: | While intrusive containers were
+ and are widely used in C, they became more and more
+ forgotten in the C++-world due to the presence of the
+ standard containers, which don't support intrusive
+ techniques. Boost.Intrusive not only reintroduces this
+ technique to C++, but also encapsulates the
+ implementation in STL-like interfaces. Hence anyone
+ familiar with standard containers can use intrusive
+ containers with ease. |
+
+
+### Function Types
+ (mini-re-review)
+
+
+| Author: | Tobias Schwinger |
+| Review Manager: | to be determined |
+| Download: | <http://boost-sandbox.sourceforge.net/vault/> |
+| Description: | 
+This library provides a metaprogramming
+ facility
+
+to classify, decompose and
+ synthesize function-, function pointer-, function
+ reference- and member function pointer types. For
+ the purpose of this documentation, these types are
+ collectively referred to as function types (this
+ differs from the standard definition and redefines
+ the term from a programmer's perspective to refer
+ to the most common types that involve
+ functions).
+
+The classes introduced by this library
+
+shall conform to the concepts
+ of the Boost Metaprogramming library (MPL).
+
+The Function Types library enables the user
+ to:
+
+* test an arbitrary type for being a function
+ type of specified kind,
+* inspect properties of function types,
+* view and modify sub types of an encapsulated
+ function type with MPL Sequence operations,
+ and
+* synthesize function types.
+This library supports variadic functions and
+
+can be configured to support
+ non-default calling conventions.
+
+ |
+
+
+### Shmem
+
+
+| Author: | Ion Gaztanaga |
+| Review Manager: | to be determined |
+| Download: | Boost Sandbox Vault -> Memory
+ (<http://boost-sandbox.sourceforge.net/vault/index.php?direction=0&order=&directory=Memory>)
+<http://ice.prohosting.com/newfunk/boost/libs/shmem/doc/html/index.html> |
+| Description: | Shmem offers tools to simplify shared
+ memory usage in applications. These include shared
+ memory creation/destruction and synchronization
+ objects. It also implements dynamic allocation of
+ portions of a shared memory segment and an easy way to
+ construct C++ objects in shared memory.
+Apart from this, Shmem implements a
+ wide range of STL-like containers and allocators that
+ can be safely placed in shared memory, helpful to
+ implement complex shared memory data-bases and other
+ efficient inter-process communications. |
+
+
+### Fusion
+
+
+| Author: | Joel de Guzman |
+| Review Manager: | to be determined |
+| Download: | <http://spirit.sourceforge.net/dl_more/fusion_v2/>
+<http://spirit.sourceforge.net/dl_more/fusion_v2.zip> |
+| Description: | Fusion is a library of heterogenous
+ containers and views and algorithms. A set of
+ heterogenous containers (vector, list, set and map) is
+ provided out of the box along with view classes that
+ present various composable views over the data. The
+ containers and views follow a common sequence concept
+ with an underlying iterator concept that binds it all
+ together, suitably making the algorithms fully generic
+ over all sequence types.
+The architecture is somewhat modeled
+ after MPL which in turn is modeled after STL. It is
+ code-named "fusion" because the library is the "fusion"
+ of compile time metaprogramming with runtime
+ programming. |
+
+
+### Pimpl
+ Pointer
+
+
+| Author: | Asger Mangaard |
+| Review Manager: | to be determined |
+| Download: | Boost Sandbox (<http://boost-consulting.com/vault/>)
+ under pimpl\_ptr. |
+| Description: | The pimpl idiom is widely used to
+ reduce compile times and disable code coupling. It does
+ so by moving private parts of a class from the .hpp file
+ to the .cpp file. However, it's implementation can be
+ tricky, and with many pitfalls (especially regarding
+ memory management). The pimpl\_ptr library is a single
+ header file, implementing a special policy based smart
+ pointer to greately ease the implementation of the pimpl
+ idiom. |
+
+
+### Type\_Traits (modification)
+
+
+| Author: | Alexander Nasonov |
+| Review Manager: | to be determined |
+| Download: | <http://cpp-experiment.sourceforge.net/promote-20050917.tar.gz>
+ or <http://cpp-experiment.sourceforge.net/promote-20050917/> |
+| Description: | Proposal to add promote,
+ integral\_promotion and floating\_point\_promotion class
+ templates to type\_traits library.
+Alexander tried it on different compilers with
+ various success: GNU/Linux (gentoo-hardened): gcc 3.3
+ and 3.4, Intel 7, 8 and 9 Windows: VC7 free compiler
+ Sparc Solaris: Sun C++ 5.3 and 5.7
+See comments at the beginning of
+ promote\_enum\_test.cpp for what is broken. <http://cpp-experiment.sourceforge.net/promote-20050917/libs/type_traits/test/promote_enum_test.cpp>
+Alexander requests a fast-track
+ review. |
+
+
+Libraries under
+ development
+----------------------------
+### Property
+ Tree
+
+
+| Author: | Marcin Kalicinski |
+| Download: | Boost Sandbox Vault (<http://boost-consulting.com/vault/>)
+ property\_tree\_rev3.zip |
+
+
+Please let us know of any libraries you are currently
+ developing that you intend to submit for review.
+
+
+
+
+
+
+

development/report-jun-2009.html

@@ -0,0 +1,646 @@
+---
+title: Review Wizard Status Report for June 2009
+copyright: 
+revised: 
+---
+
+
+Review Wizard Status Report for June 2009
+
+
+
+Review Wizard Status Report for June 2009
+=========================================
+
+News
+----
+
+
+Futures: Williams variant Accepted; Gaskill variant Rejected
+Boost 1.38 Released
+New Libraries:
+Revised Libraries:
+
+Boost.Range Extension Accepted
+
+
+Polynomial Library Rejected
+
+
+Boost 1.39 Released
+
+
+Constrained Value Review - Review Result Pending
+
+Library Issues
+==============
+
+
+The Time Series Library, accepted in August 2007, has not yet been
+submitted to SVN. Eric Niebler and John Phillips are working on
+making the changes suggested during the review.
+
+
+The Floating Point Utilities Library, has not yet been submitted to
+SVN. It is slated to be integrated with the Boost.Math library.
+
+
+The Switch Library, accepted provisionally in January 2008,
+has not yet been submitted for mini-review and full acceptance.
+
+
+The Phoenix Library, accepted provisionally in September 2008, has not
+yet been submitted for mini-review and full acceptance. A rewrite of
+Phoenix, basing it on the Proto metaprogramming library, has just
+begun.
+
+
+Maintenance of The Property Tree Library has been taken over by
+Sebastian Redl from Marcin Kalicinski. The library has been checked
+into svn trunk, but Sebastian is doing major maintenance on it in a
+branch. He is aiming for a 1.41 or 1.40 release.
+
+General Announcements
+=====================
+
+
+As always, we need experienced review managers. The review queue has
+been growing substantially but we have had few volunteers, so manage
+reviews if possible and if not please make sure to watch the review
+schedule and participate. 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 osl dot iu dot edu"
+and "phillips at mps dot ohio-state dot edu" respectively.
+
+
+We are also suffering from a lack of reviewers. While we all
+understand time pressures and the need to complete paying work, the
+strength of Boost is based on the detailed and informed reviews
+submitted by you. A recent effort is trying to secure at least five
+people who promise to submit reviews as a precondition to starting
+the review period. Consider volunteering for this and even taking the
+time to create the review as early as possible. No rule says you can
+only work on a review during the review period.
+
+
+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 a 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
+============
+
+
+* Lexer
+* Shifted Pointer
+* Logging
+* Log
+* Join
+* Pimpl
+* Thread Pool
+* Endian
+* Meta State Machine
+* Conversion
+* Sorting
+* GIL.IO
+* AutoBuffer
+* String Convert
+
+---
+Lexer
+-----
+
+
+| Author: | Ben Hanson |
+| Review Manager: | Eric Niebler |
+| Download: | [Boost Vault](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. |
+
+Shifted Pointer
+---------------
+
+
+| Author: | Phil Bouchard |
+| Review Manager: | Needed |
+| Download: | [Boost Vault](http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directory=Memory) |
+| Description: | Smart pointers are in general optimized for a specific resource
+(memory usage, CPU cycles, user friendliness, ...) depending on
+what the user need to make the most of. The purpose of this smart
+pointer is mainly to allocate the reference counter (or owner) and
+the object itself at the same time so that dynamic memory management
+is simplified thus accelerated and cheaper on the memory map. |
+
+Logging
+-------
+
+
+| Author: | John Torjo |
+| Review Manager: | Gennadiy Rozental |
+| 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! |
+
+Log
+---
+
+
+| Author: | Andrey Semashev |
+| Review Manager: | Needed |
+| Download: | [Boost Vault](http://tinyurl.com/cm9lum) |
+| Description: | The library is aimed to help adding logging features to
+applications. It provides out-of-box support for many widely used
+capabilities, such as formatting and filtering based on attributes,
+sending logs to a syslog server or to Windows Event Log, or simply
+storing logs into files. It also provides basic support for the
+library initialization from a settings file. The library can also be
+used for a wider range of tasks and implement gathering and processing
+statistical information or notifying user about application events. |
+
+Join
+----
+
+
+| Author: | Yigong Liu |
+| Review Manager: | Needed |
+| Download: | <http://channel.sourceforge.net/> |
+| Description: | Join is an asynchronous, message based C++ concurrency
+library based on join calculus. It is applicable both to
+multi-threaded applications and to the orchestration of asynchronous,
+event-based applications. It follows Comega's design and
+implementation and builds with Boost facilities. It provides a high
+level concurrency API with asynchronous methods, synchronous methods,
+and chords which are "join-patterns" defining the synchronization,
+asynchrony, and concurrency. |
+
+Pimpl
+-----
+
+
+| Author: | Vladimir Batov |
+| Review Manager: | Needed |
+| Download: | 
+[Boost Vault](http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=Pimpl.zip&directory=&)
+<http://www.ddj.com/cpp/205918714> (documentation)
+ |
+| Description: | The Pimpl idiom is a simple yet robust technique to
+minimize coupling via the separation of interface and implementation
+and then implementation hiding. This library provides a convenient
+yet flexible and generic deployment technique for the Pimpl idiom.
+It's seemingly complete and broadly applicable, yet minimal, simple
+and pleasant to use. |
+
+Thread Pool
+-----------
+
+
+| Author: | Oliver Kowalke |
+| Review Manager: | Needed |
+| Download: | [Boost Vault](http://www.boostpro.com/vault/index.php?action=downloadfile&amp;filename=boost-threadpool.2.tar.gz&amp;directory=Concurrent%20Programming) |
+| Description: | 
+The library provides:
+* thread creation policies: determines the management of worker threads:
+
+	+ fixed set of threads in pool
+	+ create workerthreads on demand (depending on context)
+	+ let worker threads ime out after certain idle time
+* channel policies: manages access to queued tasks:
+
+	+ bounded channel with high and low watermark for queuing tasks
+	+ unbounded channel with unlimited number of queued tasks
+	+ rendezvous syncron hand-over between producer and consumer threads
+* queueing policy: determines how tasks will be removed from channel:
+
+	+ FIFO
+	+ LIFO
+	+ priority queue (attribute assigned to task)
+	+ smart insertions and extractions (for instance remove oldest task with certain attribute by newst one)
+* tasks can be chained and lazy submit of taks is also supported (thanks to
+Braddocks future library).
+* returns a task object from the submit function. The task it self can
+be interrupted if its is cooperative (means it has some interruption points
+in its code -> this\_thread::interruption\_point() ).
+ |
+
+Endian
+------
+
+
+| Author: | Beman Dawes |
+| Review Manager: | Needed |
+| Download: | <http://mysite.verizon.net/beman/endian-0.10.zip> |
+| Description: | Header boost/integer/endian.hpp provides integer-like byte-holder
+binary types with explicit control over byte order, value type, size,
+and alignment. Typedefs provide easy-to-use names for common
+configurations.
+These types provide portable byte-holders for integer data,
+independent of particular computer architectures. Use cases almost
+always involve I/O, either via files or network connections. Although
+data portability is the primary motivation, these integer byte-holders
+may also be used to reduce memory use, file size, or network activity
+since they provide binary integer sizes not otherwise available. |
+
+Meta State Machine
+------------------
+
+
+| Author: | Christophe Henry |
+| Review Manager: | Needed |
+| Download: | [Boost Vault](http://www.boostpro.com/vault/index.php?direction=0&amp;order=&amp;directory=Msm) |
+| Description: | Msm is a framework which enables you to build a Finite State Machine
+in a straightforward, descriptive and easy-to-use manner . It requires
+minimal effort to generate a working program from an UML state machine
+diagram. This work was inspired by the state machine described in the
+book of David Abrahams and Aleksey Gurtovoy "C++ Template
+Metaprogramming" and adds most of what UML Designers are expecting
+from an UML State Machine framework:* Entry and Exit Methods
+* Guard Conditions
+* Sub state machines (also called composite states in UML)
+* History
+* Terminate Pseudo-State
+* Deferred Events
+* Orthogonal zones
+* Explicit entry into sub state machine states
+* Fork
+* Entry / Exit pseudo states
+* Conflicting transitions
+ |
+
+Conversion
+----------
+
+
+| Author: | Vicente Botet |
+| Review Manager: | Needed |
+| Download: | [Boost Vault](http://www.boostpro.com/vault/index.php?action=downloadfile&amp;filename=conversion.zip&amp;directory=Utilities&amp;) |
+| Description: | Generic explicit conversion between unrelated types.
+
+Boost.Conversion provides:
+* a generic convert\_to function which can be specialized by the user to
+make explicit conversion between unrelated types.
+* a generic assign\_to function which can be specialized by the user to
+make explicit assignation between unrelated types.
+* conversion between std::complex of explicitly convertible types.
+* conversion between std::pair of explicitly convertible types.
+* conversion between boost::optional of explicitly convertible types.
+* conversion between boost::rational of explicitly convertible types.
+* conversion between boost::interval of explicitly convertible types.
+* conversion between boost::chrono::time\_point and boost::ptime.
+* conversion between boost::chrono::duration and boost::time\_duration.
+ |
+
+Sorting
+-------
+
+
+| Author: | Steven Ross |
+| Review Manager: | Needed |
+| Download: | [Boost Vault](http://www.boostpro.com/vault/index.php?action=downloadfile&amp;filename=algorithm_sorting.zip) |
+| Description: | A grouping of 3 templated hybrid radix/comparison-based sorting
+algorithms that provide superior worst-case and average-case
+performance to std::sort: integer\_sort, which sorts fixed-size data
+types that support a rightshift (default of >>) and a comparison
+(default of <) operator. float\_sort, which sorts standard
+floating-point numbers by safely casting them to integers.
+string\_sort, which sorts variable-length data types, and is optimized
+for 8-bit character strings.
+All 3 algorithms have O(n(k/s + s)) runtime where k is the number of
+bits in the data type and s is a constant, and limited memory overhead
+(in the kB for realistic inputs). In testing, integer\_sort varies
+from 35% faster to 8X as fast as std::sort, depending on processor,
+compiler optimizations, and data distribution. float\_sort is roughly
+7X as fast as std::sort on x86 processors. string\_sort is roughly 2X
+as fast as std::sort. |
+
+GIL.IO
+------
+
+
+| Author: | Christian Henning |
+| Review Manager: | Needed |
+| Download: | [GIL Google Code Vault](http://gil-contributions.googlecode.com/files/rc2.zip) |
+| Description: | I/O extension for boost::gil which allows reading and
+writing of/in various image formats ( tiff, jpeg, png, etc ). This
+review will also include the Toolbox extension which adds some common
+functionality to gil, such as new color spaces, algorithms, etc. |
+
+AutoBuffer
+----------
+
+
+| Author: | Thorsten Ottosen |
+| Review Manager: | Robert Stewart |
+| Download: | [Here](http://www.cs.aau.dk/~nesotto/boost/auto_buffer.zip) |
+| Description: | Boost.AutoBuffer provides a container for efficient dynamic, local buffers.
+Furthermore, the container may be used as an alternative to std::vector,
+offering greater flexibility and sometimes better performance. |
+
+String Convert
+--------------
+
+
+| Author: | Vladimir Batov |
+| Review Manager: | Needed |
+| Download: | [Boost Vault](http://www.boostpro.com/vault/index.php?action=downloadfile&amp;filename=boost-string-convert.zip) |
+| Description: | The library takes the approach of boost::lexical\_cast in the area of
+string-to-type and type-to-string conversions, builds on the past
+boost::lexical\_cast experience and advances that conversion
+functionality further to additionally provide:
+\* throwing and non-throwing conversion-failure behavior;
+\* support for the default value to be returned when conversion fails;
+\* two types of the conversion-failure check -- basic and better/safe;
+\* formatting support based on the standard I/O Streams and the standard
+(or user-defined) I/O Stream-based manipulators
+(like std::hex, std::scientific, etc.);
+\* locale support;
+\* support for boost::range-compliant char and wchar\_t-based string containers;
+\* no DefaultConstructibility requirement for the Target type;
+\* consistent framework to uniformly incorporate any type-to-type conversions.
+It is an essential tool with applications making extensive use of
+configuration files or having to process/prepare considerable amounts
+of data in, say, XML, etc. |
+
+
+Libraries under development
+===========================
+
+
+Please let us know of any libraries you are currently
+developing that you intend to submit for review.
+Mirror
+------
+
+
+| Author: | Matus Chochlik |
+| Download: | 
+<http://svn.boost.org/svn/boost/sandbox/mirror/doc/index.html>
+[Boost Vault](http://www.boostpro.com/vault/index.php?action=downloadfile&amp;filename=mirror.zip)
+ |
+| Description: | The aim of the Mirror library is to provide useful meta-data at both
+compile-time and run-time about common C++ constructs like namespaces,
+types, typedef-ined types, classes and their base classes and member
+attributes, instances, etc. and to provide generic interfaces for
+their introspection.
+Mirror is designed with the principle of stratification in mind and
+tries to be as less intrusive as possible. New or existing classes do
+not need to be designed to directly support Mirror and no Mirror
+related code is necessary in the class' definition, as far as some
+general guidelines are followed
+Most important features of the Mirror library that are currently
+implemented include:
+
+* Namespace-name inspection.
+* Inspection of the whole scope in which a namespace is defined
+* Type-name querying, with the support for typedef-ined typenames
+and typenames of derived types like pointers, references,
+cv-qualified types, arrays, functions and template names. Names
+with or without nested-name-specifiers can be queried.
+* Inspection of the scope in which a type has been defined
+* Uniform and generic inspection of class' base classes. One can
+inspect traits of the base classes for example their types,
+whether they are inherited virtually or not and the access
+specifier (private, protected, public).
+* Uniform and generic inspection of class' member attributes. At
+compile-time the count of class' attributes and their types,
+storage class specifiers (static, mutable) and some other traits
+can be queried. At run-time one can uniformly query the names
+and/or values (when given an instance of the reflected class) of
+the member attributes and sequentially execute a custom functor
+on every attribute of a class.
+* Traversals of a class' (or generally type's) structure with user
+defined visitors, which are optionally working on an provided
+instance of the type or just on it's structure without any
+run-time data. These visitors are guided by Mirror through the
+structure of the class and optionally provided with contextual
+information about the current position in the traversal.
+I'm hoping to have it review ready in the next few months. |
+
+Interval Template Library
+-------------------------
+
+
+| Author: | Joachim Faulhaber |
+| Description: | The Interval Template Library (Itl) provides intervals
+and two kinds of interval containers: Interval\_sets and
+interval\_maps. Interval\_sets and maps can be used just
+as sets or maps of elements. Yet they are much more
+space and time efficient when the elements occur in
+contiguous chunks: intervals. This is obviously the case
+in many problem domains, particularly in fields that deal
+with problems related to date and time.
+Interval containers allow for intersection with interval\_sets
+to work with segmentation. For instance you might want
+to intersect an interval container with a grid of months
+and then iterate over those months.
+Finally interval\_maps provide aggregation on
+associated values, if added intervals overlap with
+intervals that are stored in the interval\_map. This
+feature is called aggregate on overlap. It is shown by
+example:
+
+```
+
+typedef set<string> guests;
+interval\_map<time, guests> party;
+guests mary; mary.insert("Mary");
+guests harry; harry.insert("Harry");
+party += make\_pair(interval<time>::rightopen(20:00, 22:00),mary);
+party += make\_pair(interval<time>::rightopen\_(21:00, 23:00),harry);
+// party now contains
+[20:00, 21:00)->{"Mary"}
+[21:00, 22:00)->{"Harry","Mary"} //guest sets aggregated on overlap
+[22:00, 23:00)->{"Harry"}
+
+```
+
+As can be seen from the example an interval\_map has both
+a decompositional behavior (on the time dimension) as well as
+a accumulative one (on the associated values). |
+
+StlConstantTimeSize
+-------------------
+
+
+| Author: | Vicente J. Botet Escriba |
+| Download: | [Boost Vault](http://www.boostpro.com/vault/index.php?action=downloadfile&filename=constant_time_size.zip&amp;directory=Containers&amp;) |
+| Description: | Boost.StlConstantTimeSize Defines a wrapper to the stl container list
+giving the user the chioice for the complexity of the size function:
+linear time, constant time or quasi-constant. In future versions the
+library could include a similar wrapper to slist. |
+
+InterThreads
+------------
+
+
+| Author: | Vicente J. Botet Escriba |
+| Download: | [Boost Vault](http://www.boostpro.com/vault/index.php?action=downloadfile&amp;filename=interthreads.zip&amp;directory=Concurrent%20Programming&amp;) |
+| Description: | Boost.InterThreads extends Boost.Threads adding some features:
+
+* thread decorator: thread\_decorator allows to define
+setup/cleanup functions which will be called only once by
+thread: setup before the thread function and cleanup at thread
+exit.
+* thread specific shared pointer: this is an extension of the
+thread\_specific\_ptr providing access to this thread specific
+context from other threads. As it is shared the stored pointer
+is a shared\_ptr instead of a raw one.
+* thread keep alive mechanism: this mechanism allows to detect
+threads that do not prove that they are alive by calling to the
+keep\_alive\_point regularly. When a thread is declared dead a
+user provided function is called, which by default will abort
+the program.
+* thread tuple: defines a thread groupe where the number of
+threads is know statically and the threads are created at
+construction time.
+* set\_once: a synchonizer that allows to set a variable only once,
+notifying to the variable value to whatever is waiting for that.
+* thread\_tuple\_once: an extension of the boost::thread\_tuple which
+allows to join the thread finishing the first, using for that
+the set\_once synchronizer.
+* thread\_group\_once: an extension of the boost::thread\_group which
+allows to join the thread finishing the first, using for that
+the set\_once synchronizer.
+(thread\_decorator and thread\_specific\_shared\_ptr) are based on the
+original implementation of threadalert written by Roland Schwarz.
+Boost.InterThreads extends Boost.Threads adding thread setup/cleanup
+decorator, thread specific shared pointer, thread keep alive
+mechanism and thread tuples. |
+
+Channel
+-------
+
+
+| Author: | Yigong Liu |
+| Download: | <http://channel.sourceforge.net> |
+| Description: | Channel is a C++ template library to provide name spaces for distributed
+message passing and event dispatching. Message senders and receivers bind to
+names in name space; binding and matching rules decide which senders will
+bind to which receivers (the binding-set); then message passing could happen
+among bound senders and receivers.
+The type of name space is a template parameter of Channel. Various name
+spaces (linear/hierarchical/associative) can be used for different
+applications. For example, integer ids can be used to send messages in
+linear name space, string path name ids (such as "/sports/basketball") can
+be used to send messages in hierarchical name space and regex patterns or
+Linda tuple-space style tuples can be used to send messages in associative
+name space.
+Dispatcher is another configurable template parameter of Channel; which
+dispatch messages/events from senders to bounded receivers. The design of
+dispatchers can vary in several dimensions:
+how msgs move: push or pull;
+how callbacks executed: synchronous or asynchronous.
+Sample dispatchers includes : synchronous broadcast dispatcher, asynchronous
+dispatchers with choice\_arbiter and join\_arbiters.
+Name space and dispatchers are orthogonal; they can mix and match together
+freely. Name spaces and name-binding create binding-sets for sender and
+receiver, and dispatchers are algorithms defined over the binding-set.
+Distributed channels can be connected to allow transparent distributed
+message passing. Filters and translators are used to control name space
+changes. |
+
+Bitfield
+--------
+
+
+| Authot: | Vicente Botet |
+| Download: |  |
+| Description: |  |
+
+
+I have adapted the Bitfield library from Emile Cormier with its
+permision and I would like you add it to the libraries under
+developement list. The library is quite stable but I want to add some
+test with Boost.Endian before adding it to the formal review schedule
+list.
+Boost.Bitfield consists of:
+* a generic bitfield traits class providing generic getter and setter methods.
+* a BOOST\_BITFIELD\_DCL macro making easier the definition of the
+bitfield traits and the bitfield getter and setter functions:
+```
+
+struct X {
+    typedef boost::ubig\_32 storage\_type;
+    storage\_type d0;
+    typedef unsigned int value\_type;
+    BOOST\_BITFIELD\_DCL(storage\_type, d0, unsigned int, d00, 0, 10);
+    BOOST\_BITFIELD\_DCL(storage\_type, d0, unsigned int, d01, 11, 31);
+};
+
+```
+
+
+
+Synchro
+-------
+
+
+| Author: | Vicente Botet |
+| Download: | [Boost Vault:](http://www.boostpro.com/vault/index.php?action=downloadfile&filename=synchro.zip&directory=Concurrent%20Programming&)
+[Boost Sandbox:](https://svn.boost.org/svn/boost/sandbox/synchro)
+Html doc included only on the Vault |
+| Description: | Synchro provides: |
+
+
+* A uniform usage of Boost.Thread and Boost.Interprocess
+synchronization mechanisms based on lockables(mutexes) concepts and
+locker(guards) concepts.
+> 
+> 
+> 	+ lockables traits and lock generators,
+> 	+ generic free functions on lockables as: lock, try\_lock, ...
+> 	+ locker adapters of the Boost.Thread and Boost.Interprocess lockers models,
+> 	+ complete them with the corresponding models for single-threaded
+> 	programms: null\_mutex and null\_condition classes,
+> 	+ locking families,
+> 	+ semaphore and binary\_semaphore,
+> 	+ condition\_lockable lock which put toghether a lock and its
+> 	associated conditions.
+>
+* A coherent exception based timed lock approach for functions and constructors,
+* A rich palete of lockers as
+> 
+> 
+> 	+ strict\_locker, nested\_strict\_locker,
+> 	+ condition\_locker,
+> 	+ reverse\_locker, nested\_reverse\_locker,
+> 	+ locking\_ptr, on\_derreference\_locking\_ptr,
+> 	+ externally\_locked,
+>
+* array\_unique\_locker on multiple lockables.
+* Generic free functions on multiple lockables lock, try\_lock,
+lock\_until, lock\_for, try\_lock\_until, try\_lock\_for, unlock
+* lock adapters of the Boost.Thread and Boost.Interprocess lockable models,
+* lock\_until, lock\_for, try\_lock\_until, try\_lock\_for
+* A polymorphic lockable hierarchy.
+* High-level abstractions for handling more complicated
+synchronization problems, including
+> 
+> 
+> 	+ monitor for guaranteeing exclusive access to an object.
+>
+* A rendezvous mechanism for handling direct communication between
+objects concurrent\_components via ports using an
+accept-synchronize protocol based on the design of the concurrency
+library in the Beta language.
+* Language-like Synchronized Block Macros
+

development/report-may-2008.html

@@ -0,0 +1,462 @@
+---
+title: Review Wizard Status Report for May 2008
+copyright: 
+revised: 
+---
+
+
+Review Wizard Status Report for May 2008
+
+
+
+Review Wizard Status Report for May 2008
+========================================
+
+News
+----
+
+
+December 7, 2007 - Forward Library Accepted - Awaiting
+ SVN
+
+
+December 16 - Unordered Containers Library Accepted - In
+ SVN
+
+
+December 21 - Factory Library Accepted - Awaiting SVN
+
+
+January 13, 2008 - Switch Library Accepted Provisionally -
+ Awaiting submission for mini review
+
+
+January 18 - Singleton Library Rejected - Awaiting
+ resubmission, John Torjo has already volunteered to manage the
+ next review
+
+
+January 30 - Flyweight Library Accepted - Awaiting SVN
+
+
+February 13 - Logging Library Rejected - Awaiting
+ resubmission for new review, John Torjo has already resubmitted
+ and Gennadiy Rozental has again volunteered to manage the
+ review
+
+
+February 27 - Floating Point Utilities Library Accepted -
+ Awaiting SVN
+
+
+March 14 - Proto Library Accepted - Exists as a component in
+ Xpressive, but not yet as a separate library
+
+
+April 20 - Egg review completed - Results pending
+
+
+May 7 - Scope Exit Library Accepted - Awaiting SVN
+
+Older
+ Issues
+=============
+
+
+The binary\_int library, accepted in October 2005 has not yet
+ been submitted to SVN. The authors are strongly encouraged to
+ contact the review wizards
+
+
+The Quantitative Units library, accepted in April 2007 has
+ not yet been submitted to SVN
+
+
+The Globally Unique Identifier library, accepted
+ provisionally in May 2007 has not yet been submitted for
+ mini-review and full acceptance
+
+
+The Time Series Library, accepted in August 2007 has not yet
+ been submitted to SVN
+
+
+The Accumulators library, accepted in February 2007 is in
+ SVN
+
+
+The Exception library, accepted in October 2007 is in
+ SVN
+
+
+The Scope Exit review report had not been submitted by the
+ review manager. John Phillips stepped in as substitute review
+ manager and produced a report
+
+
+For libraries that are still waiting to get into SVN, please
+ get them ready and into the repository. The developers did some
+ great work making the libraries, so don't miss the chance to
+ share that work with others. Also notice that the review
+ process page has been updated with a section on rights and
+ responsibilities of library submitters.
+
+
+For the Scope Exit review, we would like to publicly
+ apologize to Alexander Nasonov for how long this has languished
+ without a report. The review wizards will work to make sure
+ this doesn't happen any more.
+
+General Announcements
+=====================
+
+
+As always, we need experienced review managers. In the past
+ few months there have been a large number of reviews, but the
+ flow of high quality submissions is just as big, so manage
+ reviews if possible and if not please make sure to watch the
+ review schedule and participate. 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 "phillips at
+ mps dot ohio-state 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 a 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
+* Property Map (fast-track)
+* Graph (fast-track)
+* Lexer
+* Thread-Safe Signals
+* Boost.Range (Update)
+* Shifted Pointer
+* DataFlow Signals
+* Logging
+* Futures (Braddock Gaskill)
+* Futures (Anthony Williams)
+* Join (Yigong Liu)
+* Pimpl (Vladimir Batov)
+
+---
+Finite State Machines
+---------------------
+
+
+| Author: | Andrey Semashev |
+| Review Manager: | Martin Vuille |
+| Download: | [Boost Sandbox
+ Vault](http://tinyurl.com/yjozfn) |
+| 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.
+ |
+
+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](http://svn.boost.org/trac/boost/browser/sandbox/graph-v2/libs/property_map/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.
+* run-time 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.
+ |
+
+Lexer
+-----
+
+
+| Author: | Ben Hanson |
+| Review Manager: | Eric Neibler |
+| Download: | [Boost Sandbox Vault](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: | [Boost Sandbox Vault](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. |
+
+Boost.Range (Update)
+--------------------
+
+
+| Author: | Neil Groves |
+| Review Manager: | Needed |
+| Download: | [Boost Sandbox Vault](http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=range_ex.zip&directory=) |
+| Description: | A significant update of the
+ range library, including range adapters. |
+
+Shifted
+ Pointer
+----------------
+
+
+| Author: | Phil Bouchard |
+| Review Manager: | Needed |
+| Download: | [Boost Sandbox Vault](http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directory=Memory) |
+| Description: | Smart pointers are in general
+ optimized for a specific resource (memory usage, CPU
+ cycles, user friendliness, ...) depending on what the
+ user need to make the most of. The purpose of this
+ smart pointer is mainly to allocate the reference
+ counter (or owner) and the object itself at the same
+ time so that dynamic memory management is simplified
+ thus accelerated and cheaper on the memory map. |
+
+DataFlow
+ Signals
+-----------------
+
+
+| Author: | Stjepan Rajko |
+| Review Manager: | Needed |
+| Download: | <http://dancinghacker.com/code/dataflow/> |
+| Description: | Dataflow is a generic library
+ for dataflow programming. Dataflow programs can
+ typically be expressed as a graph in which vertices
+ represent components that process data, and edges
+ represent the flow of data between the components. As
+ such, dataflow programs can be easily reconfigured by
+ changing the components and/or the connections. |
+
+Logging
+-------
+
+
+| Author: | John Torjo |
+| Review Manager: | Gennadiy Rozental |
+| 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! |
+
+Futures
+-------
+
+
+| Author: | Braddock Gaskill |
+| Review Manager: | Needed |
+| Download: | <http://braddock.com/~braddock/future/> |
+| Description: | The goal of the boost.future
+ library is to provide a definitive future
+ implementation with the best features of the numerous
+ implementations, proposals, and academic papers
+ floating around, in the hopes to avoid multiple
+ incompatible future implementations in libraries of
+ related concepts (coroutines, active objects, asio,
+ etc). This library hopes to explore the combined
+ implementation of the best future concepts. |
+
+Futures
+-------
+
+
+| Author: | Anthony Williams |
+| Review Manager: | Needed |
+| Download: | <http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp>
+ (code) <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2561.html>
+ (description) |
+| Description: | This paper proposes a kind of return
+ buffer that takes a value (or an exception) in one
+ (sub-)thread and provides the value in another
+ (controlling) thread. This buffer provides
+ essentially two interfaces:
+
+* an interface to assign a value as class
+ promise and
+* an interface to wait for, query and retrieve
+ the value (or exception) from the buffer as
+ classes unique\_future and shared\_future. While a
+ unique\_future provides move semantics where the
+ value (or exception) can be retrieved only once,
+ the shared\_future provides copy semantics where
+ the value can be retrieved arbitrarily
+ often.
+A typical procedure for working with promises and
+ futures looks like:
+
+* control thread creates a promise,
+* control thread gets associated future from
+ promise,
+* control thread starts sub-thread,
+* sub-thread calls actual function and assigns
+ the return value to the promise,
+* control thread waits for future to become
+ ready,
+* control thread retrieves value from
+ future.
+Also proposed is a packaged\_task that wraps one
+ callable object and provides another one that can be
+ started in its own thread and assigns the return
+ value (or exception) to a return buffer that can be
+ accessed through one of the future classes.
+With a packaged\_task a typical procedure looks
+ like:
+
+* control thread creates a packaged\_task with a
+ callable object,
+* control thread gets associated future from
+ packaged\_task,
+* control thread starts sub-thread, which
+ invokes the packaged\_task,
+* packaged\_task calls the callable function and
+ assigns the return value,
+* control thread waits for future to become
+ ready,
+* control thread retrieves value from
+ future.
+
+
+ |
+
+
+Notice that we are in the unusual position of having two
+ very different libraries with the same goal in the queue at
+ the same time. The Review Wizards would appreciate a
+ discussion of the best way to hold these two reviews to
+ produce the best possible addition to Boost.
+
+Join
+----
+
+
+| Author: | Yigong Liu |
+| Review Manager: | Needed |
+| Download: | <http://channel.sourceforge.net/> |
+| Description: | Join is an asynchronous, message
+ based C++ concurrency library based on join calculus.
+ It is applicable both to multi-threaded applications
+ and to the orchestration of asynchronous, event-based
+ applications. It follows Comega's design and
+ implementation and builds with Boost facilities. It
+ provides a high level concurrency API with asynchronous
+ methods, synchronous methods, and chords which are
+ "join-patterns" defining the synchronization,
+ asynchrony, and concurrency. |
+
+Pimpl
+-----
+
+
+| Author: | Vladimir Batov |
+| Review Manager: | Needed |
+| Download: | [Boost Sandbox Vault](http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=Pimpl.zip&directory=&) <http://www.ddj.com/cpp/205918714>
+ (documentation) |
+| Description: | The Pimpl idiom is a simple yet
+ robust technique to minimize coupling via the
+ separation of interface and implementation and then
+ implementation hiding. This library provides a
+ convenient yet flexible and generic deployment
+ technique for the Pimpl idiom. It's seemingly complete
+ and broadly applicable, yet minimal, simple and
+ pleasant to use. |
+
+
+Libraries under
+ development
+============================
+
+
+Please let us know of any libraries you are currently
+ developing that you intend to submit for review.
+
+
+
+

development/report-nov-2007.html

@@ -0,0 +1,340 @@
+---
+title: Review Wizard Status Report for November 2007
+copyright: 
+revised: 2007-10-22 22:55:52 +0100
+---
+
+
+Review Wizard Status Report for November 2007
+
+
+
+Review Wizard Status Report for November 2007
+=============================================
+
+News
+----
+November 7, 2007 - Exception Library Accepted
+Announcement: <https://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](http://tinyurl.com/yjozfn) |
+| 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](http://boost-consulting.com/vault/index.php?directory=Math%20-%20Numerics) |
+| 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](http://boost-consulting.com/vault/index.php?action=downloadfile&filename=mcs_units_v0.7.1.zip&directory=Units) |
+| 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](http://svn.boost.org/trac/boost/browser/sandbox/graph-v2/libs/property_map/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.
+
+
+
+
+
+
+
+
+

development/report-nov-2008.html

@@ -0,0 +1,562 @@
+---
+title: Review Wizard Status Report for November 2008
+copyright: 
+revised: 
+---
+
+
+Review Wizard Status Report for November 2008
+
+
+
+Review Wizard Status Report for November 2008
+=============================================
+
+News
+----
+
+
+May 7 - Scope Exit Library Accepted - Awaiting SVN
+
+
+May 17 - Egg Library Rejected
+August 14 - Boost 1.36 Released
+New Libraries: Accumulators, Exception, Units, Unordered Containers
+
+August 27 - Finite State Machines Rejected
+
+
+September 10 - Data Flow Signals Rejected
+
+
+September 30 - Phoenix Accepted Conditionally
+November 3 - Boost 1.37 Released
+New Library: Proto
+
+November 10 - Thread-Safe Signals Accepted - Awaiting SVN
+
+
+November 25 - Globally Unique Identifier Library mini-Review in progress
+
+Older Issues
+============
+
+
+The Quantitative Units library, accepted in April 2007 is in SVN
+(listed as units).
+
+
+The Time Series Library, accepted in August 2007, has not yet been
+submitted
+to SVN.
+
+
+The Switch Library, accepted provisionally in January 2008,
+has not yet been submitted for mini-review and full acceptance.
+
+
+Property Map (Fast-Track) and Graph (Fast-Track) have been removed
+from the review queue. The author (Andrew Sutton) intends to submit a
+new version of this work at a later time.
+
+
+A few libraries have been reviewed and accepted into boost, but have
+not yet appeared in SVN as far as I can tell. Could some light be
+shed on the status of the following libraries? Apologies if I have
+simply overlooked any of them:
+
+
+* Flyweight (Joaquin Ma Lopez Munoz)
+* Floating Point Utilities (Johan Rade)
+* Factory (Tobias Schwinger)
+* Forward (Tobias Schwinger)
+* Scope Exit (Alexander Nasonov)
+* Time Series (Eric Niebler)
+* Property Tree (Marcin Kalicinski) -- No documentation in SVN
+
+
+Any information on the whereabouts of these libraries would be greatly
+appreciated.
+
+
+For libraries that are still waiting to get into SVN, please get them
+ready and into the repository. The developers did some great work
+making the libraries, so don't miss the chance to share that work with
+others. Also notice that the review process page has been updated with
+a section on rights and responsibilities of library submitters.
+
+General Announcements
+=====================
+
+
+As always, we need experienced review managers. The review queue has
+been growing substantially but we have had few volunteers, so manage
+reviews if possible and if not please make sure to watch the review
+schedule and participate. 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 osl dot iu dot edu"
+and "phillips at mps dot ohio-state dot edu" respectively.
+
+
+We are also suffering from a lack of reviewers. While we all
+understand time pressures and the need to complete paying work, the
+strength of Boost is based on the detailed and informed reviews
+submitted by you. A recent effort is trying to secure at least five
+people who promise to submit reviews as a precondition to starting
+the review period. Consider volunteering for this and even taking the
+time to create the review as early as possible. No rule says you can
+only work on a review during the review period.
+
+
+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 a 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
+============
+
+
+* Lexer
+* Boost.Range (Update)
+* Shifted Pointer
+* Logging
+* Futures - Williams
+* Futures - Gaskill
+* Join
+* Pimpl
+* Constrained Value
+* Thread Pool
+* Polynomial
+
+---
+Lexer
+-----
+
+
+| Author: | Ben Hanson |
+| Review Manager: | Eric Neibler |
+| Download: | [Boost Sandbox Vault](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. |
+
+Boost.Range (Update)
+--------------------
+
+
+| Author: | Neil Groves |
+| Review Manager: | Needed |
+| Download: | [Boost Sandbox Vault](http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=range_ex.zip) |
+| Description: | A significant update of the range library, including
+range adapters. |
+
+Shifted Pointer
+---------------
+
+
+| Author: | Phil Bouchard |
+| Review Manager: | Needed |
+| Download: | [Boost Sandbox Vault](http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directory=Memory) |
+| Description: | Smart pointers are in general optimized for a specific resource
+(memory usage, CPU cycles, user friendliness, ...) depending on
+what the user need to make the most of. The purpose of this smart
+pointer is mainly to allocate the reference counter (or owner) and
+the object itself at the same time so that dynamic memory management
+is simplified thus accelerated and cheaper on the memory map. |
+
+Logging
+-------
+
+
+| Author: | John Torjo |
+| Review Manager: | Gennadiy Rozental |
+| 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! |
+
+Futures
+-------
+
+
+| Author: | Braddock Gaskill |
+| Review Manager: | Tom Brinkman |
+| Download: | <http://braddock.com/~braddock/future/> |
+| Description: | The goal of this library is to provide a definitive
+future implementation with the best features of the numerous
+implementations, proposals, and academic papers floating around, in
+the hopes to avoid multiple incompatible future implementations in
+libraries of related concepts (coroutines, active objects, asio,
+etc). This library hopes to explore the combined implementation of
+the best future concepts. |
+
+Futures
+-------
+
+
+| Author: | Anthony Williams |
+| Review Manager: | Tom Brinkman |
+| Download: | 
+<http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp>
+(code)
+<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2561.html>
+(description)
+ |
+| Description: | This library proposes a kind of return buffer that takes
+a value (or an exception) in one (sub-)thread and provides the value
+in another (controlling) thread. This buffer provides essentially
+two interfaces:* an interface to assign a value as class promise and
+* an interface to wait for, query and retrieve the value (or exception)
+from the buffer as classes unique\_future and shared\_future. While a
+unique\_future provides move semantics where the value (or exception)
+can be retrieved only once, the shared\_future provides copy semantics
+where the value can be retrieved arbitrarily often.
+
+A typical procedure for working with promises and futures looks like:* control thread creates a promise,
+* control thread gets associated future from promise,
+* control thread starts sub-thread,
+* sub-thread calls actual function and assigns the return value to
+the promise,
+* control thread waits for future to become ready,
+* control thread retrieves value from future.
+
+Also proposed is a packaged\_task that wraps one callable object and
+provides another one that can be started in its own thread and assigns
+the return value (or exception) to a return buffer that can be
+accessed through one of the future classes.
+With a packaged\_task a typical procedure looks like:* control thread creates a packaged\_task with a callable object,
+* control thread gets associated future from packaged\_task,
+* control thread starts sub-thread, which invokes the packaged\_task,
+* packaged\_task calls the callable function and assigns the return value,
+* control thread waits for future to become ready,
+* control thread retrieves value from future.
+ |
+
+
+Notice that we are in the unusual position of having two very
+different libraries with the same goal in the queue at the same
+time. The Review Wizards would appreciate a discussion of the best way
+to hold these two reviews to produce the best possible addition to
+Boost.
+
+Join
+----
+
+
+| Author: | Yigong Liu |
+| Review Manager: | Needed |
+| Download: | <http://channel.sourceforge.net/> |
+| Description: | Join is an asynchronous, message based C++ concurrency
+library based on join calculus. It is applicable both to
+multi-threaded applications and to the orchestration of asynchronous,
+event-based applications. It follows Comega's design and
+implementation and builds with Boost facilities. It provides a high
+level concurrency API with asynchronous methods, synchronous methods,
+and chords which are "join-patterns" defining the synchronization,
+asynchrony, and concurrency. |
+
+Pimpl
+-----
+
+
+| Author: | Vladimir Batov |
+| Review Manager: | Needed |
+| Download: | 
+[Boost Sandbox Vault](http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=Pimpl.zip&directory=&)
+<http://www.ddj.com/cpp/205918714> (documentation)
+ |
+| Description: | The Pimpl idiom is a simple yet robust technique to
+minimize coupling via the separation of interface and implementation
+and then implementation hiding. This library provides a convenient
+yet flexible and generic deployment technique for the Pimpl idiom.
+It's seemingly complete and broadly applicable, yet minimal, simple
+and pleasant to use. |
+
+Constrained Value
+-----------------
+
+
+| Author: | Robert Kawulak |
+| Review Manager: | Jeff Garland |
+| Download: | <http://rk.go.pl/f/constrained_value.zip> |
+| Description: | The Boost Constrained Value library contains class templates useful
+for creating constrained objects. A simple example is an object
+representing an hour of a day, for which only integers from the range
+[0, 23] are valid values:
+
+```
+
+bounded\_int<int, 0, 23>::type hour;
+hour = 20; // OK
+hour = 26; // exception!
+
+```
+
+Behavior in case of assignment of an invalid value can be customized. For
+instance, instead of throwing an exception as in the example above, the value
+may be adjusted to meet the constraint:
+
+```
+
+wrapping\_int<int, 0, 255>::type buffer\_index;
+buffer\_index = 257; // OK: wraps the value to fit in the range
+assert( buffer\_index == 1 );
+
+```
+
+The library doesn't focus only on bounded objects as in the examples above --
+virtually any constraint can be imposed by using a predicate:
+
+```
+
+// constraint (a predicate)
+struct is\_odd {
+   bool operator () (int i) const
+   { return (i % 2) != 0; }
+};
+
+```
+
+
+```
+
+// and the usage is as simple as:
+constrained<int, is\_odd> odd\_int = 1;
+odd\_int += 2; // OK
+++odd\_int; // exception!
+
+```
+
+The library has a policy-based design to allow for flexibility in defining
+constraints and behavior in case of assignment of invalid values. Policies may
+be configured at compile-time for maximum efficiency or may be changeable at
+runtime if such dynamic functionality is needed. |
+
+Thread Pool
+-----------
+
+
+| Author: | Oliver Kowalke |
+| Review Manager: | Needed |
+| Download: | [Boost Sandbox Vault](http://www.boostpro.com/vault/index.php?action=downloadfile&amp;filename=boost-threadpool.2.tar.gz&amp;directory=Concurrent%20Programming) |
+| Description: | The library provides:* thread creation policies: determines the management of worker threads
+
+	+ fixed set of threads in pool
+	+ create workerthreads on demand (depending on context)
+	+ let worker threads ime out after certain idle time
+* channel policies: manages access to queued tasks
+
+	+ bounded channel with high and low watermark for queuing tasks
+	+ unbounded channel with unlimited number of queued tasks
+	+ rendezvous syncron hand-over between producer and consumer threads
+* queueing policy: determines how tasks will be removed from channel
+
+	+ FIFO
+	+ LIFO
+	+ priority queue (attribute assigned to task)
+	+ smart insertions and extractions (for instance remove oldest task with
+	certain attribute by newst one)
+* tasks can be chained and lazy submit of taks is also supported (thanks to
+Braddocks future library).
+* returns a task object from the submit function. The task it self can
+be interrupted if its is cooperative (means it has some interruption points
+in its code -> this\_thread::interruption\_point() ).
+ |
+
+Polynomial
+----------
+
+
+| Author: | Pawel Kieliszczyk |
+| Review Manager: | Needed |
+| Download: | [Boost Sandbox Vault](http://www.boostpro.com/vault/index.php?action=downloadfile&amp;filename=polynomial.zip) |
+| Description: | The library was written to enable fast and faithful polynomial manipulation.
+It provides:* main arithmetic operators (+, -, \* using FFT, /, %),
+* gcd,
+* different methods of evaluation (Horner Scheme, Compensated Horner
+Algorithm, by preconditioning),
+* derivatives and integrals,
+* interpolation,
+* conversions between various polynomial forms (special functions for
+creating Chebyshev, Hermite, Laguerre and Legendre form).
+ |
+
+
+Libraries under development
+===========================
+
+
+Please let us know of any libraries you are currently
+developing that you intend to submit for review.
+Logging
+-------
+
+
+| Author: | Andrey Semashev |
+| Download: | <http://boost-log.sourceforge.net> |
+| Description: | I am working on a logging library, online docs available here:
+The functionality is quite ready, the docs are at about 70% ready. There
+are a few examples, but no tests yet (I'm using the examples for
+testing). I hope to submit it for a review at early 2009. |
+
+Mirror
+------
+
+
+| Author: | Matus Chochlik |
+| Download: | 
+<http://svn.boost.org/svn/boost/sandbox/mirror/doc/index.html>
+[Boost Sandbox Vault](http://www.boostpro.com/vault/index.php?action=downloadfile&filename=mirror.zip)
+ |
+| Description: | The aim of the Mirror library is to provide useful meta-data at both
+compile-time and run-time about common C++ constructs like namespaces,
+types, typedef-ined types, classes and their base classes and member
+attributes, instances, etc. and to provide generic interfaces for
+their introspection.
+Mirror is designed with the principle of stratification in mind and
+tries to be as less intrusive as possible. New or existing classes do
+not need to be designed to directly support Mirror and no Mirror
+related code is necessary in the class' definition, as far as some
+general guidelines are followed
+Most important features of the Mirror library that are currently
+implemented include:
+
+* Namespace-name inspection.
+* Inspection of the whole scope in which a namespace is defined
+* Type-name querying, with the support for typedef-ined typenames
+and typenames of derived types like pointers, references,
+cv-qualified types, arrays, functions and template names. Names
+with or without nested-name-specifiers can be queried.
+* Inspection of the scope in which a type has been defined
+* Uniform and generic inspection of class' base classes. One can
+inspect traits of the base classes for example their types,
+whether they are inherited virtually or not and the access
+specifier (private, protected, public).
+* Uniform and generic inspection of class' member attributes. At
+compile-time the count of class' attributes and their types,
+storage class specifiers (static, mutable) and some other traits
+can be queried. At run-time one can uniformly query the names
+and/or values (when given an instance of the reflected class) of
+the member attributes and sequentially execute a custom functor
+on every attribute of a class.
+* Traversals of a class' (or generally type's) structure with user
+defined visitors, which are optionally working on an provided
+instance of the type or just on it's structure without any
+run-time data. These visitors are guided by Mirror through the
+structure of the class and optionally provided with contextual
+information about the current position in the traversal.
+I'm hoping to have it review ready in the next few months. |
+
+Interval Template Library
+-------------------------
+
+
+| Author: | Joachim Faulhaber |
+| Description: | The Interval Template Library (Itl) provides intervals
+and two kinds of interval containers: Interval\_sets and
+interval\_maps. Interval\_sets and maps can be used just
+as sets or maps of elements. Yet they are much more
+space and time efficient when the elements occur in
+contiguous chunks: intervals. This is obviously the case
+in many problem domains, particularly in fields that deal
+with problems related to date and time.
+Interval containers allow for intersection with interval\_sets
+to work with segmentation. For instance you might want
+to intersect an interval container with a grid of months
+and then iterate over those months.
+Finally interval\_maps provide aggregation on
+associated values, if added intervals overlap with
+intervals that are stored in the interval\_map. This
+feature is called aggregate on overlap. It is shown by
+example:
+
+```
+
+typedef set<string> guests;
+interval\_map<time, guests> party;
+guests mary; mary.insert("Mary");
+guests harry; harry.insert("Harry");
+party += make\_pair(interval<time>::rightopen(20:00, 22:00),mary);
+party += make\_pair(interval<time>::rightopen\_(21:00, 23:00),harry);
+// party now contains
+[20:00, 21:00)->{"Mary"}
+[21:00, 22:00)->{"Harry","Mary"} //guest sets aggregated on overlap
+[22:00, 23:00)->{"Harry"}
+
+```
+
+As can be seen from the example an interval\_map has both
+a decompositional behavior (on the time dimension) as well as
+a accumulative one (on the associated values). |
+
+StlConstantTimeSize
+-------------------
+
+
+| Author: | Vicente J. Botet Escriba |
+| Download: | [Boost Sandbox Vault](http://www.boostpro.com/vault/index.php?action=downloadfile&filename=constant_time_size.zip&directory=Containers&) |
+| Description: | Boost.StlConstantTimeSize Defines a wrapper to the stl container list
+giving the user the chioice for the complexity of the size function:
+linear time, constant time or quasi-constant. In future versions the
+library could include a similar wrapper to slist. |
+
+InterThreads
+------------
+
+
+| Author: | Vicente J. Botet Escriba |
+| Download: | 
+[Boost Sandbox Vault](http://www.boostpro.com/vault/index.php?action=downloadfile&filename=interthreads.zip&directory=Concurrent%20Programming&)
+[Boost Sandbox](https://svn.boost.org/svn/boost/sandbox/interthreads)
+Html doc included only on the Vault
+ |
+| Description: | Boost.InterThreads extends Boost.Threads adding some features:
+
+* thread decorator: thread\_decorator allows to define
+setup/cleanup functions which will be called only once by
+thread: setup before the thread function and cleanup at thread
+exit.
+* thread specific shared pointer: this is an extension of the
+thread\_specific\_ptr providing access to this thread specific
+context from other threads. As it is shared the stored pointer
+is a shared\_ptr instead of a raw one.
+* thread keep alive mechanism: this mechanism allows to detect
+threads that do not prove that they are alive by calling to the
+keep\_alive\_point regularly. When a thread is declared dead a
+user provided function is called, which by default will abort
+the program.
+* thread tuple: defines a thread groupe where the number of
+threads is know statically and the threads are created at
+construction time.
+* set\_once: a synchonizer that allows to set a variable only once,
+notifying to the variable value to whatever is waiting for that.
+* thread\_tuple\_once: an extension of the boost::thread\_tuple which
+allows to join the thread finishing the first, using for that
+the set\_once synchronizer.
+* thread\_group\_once: an extension of the boost::thread\_group which
+allows to join the thread finishing the first, using for that
+the set\_once synchronizer.
+(thread\_decorator and thread\_specific\_shared\_ptr) are based on the
+original implementation of threadalert written by Roland Schwarz.
+Boost.InterThreads extends Boost.Threads adding thread setup/cleanup
+decorator, thread specific shared pointer, thread keep alive
+mechanism and thread tuples. |
+

development/report-sep-2007.html

@@ -0,0 +1,256 @@
+---
+title: Review Wizard Status Report for September 2007
+copyright: 
+revised: 2007-10-22 22:55:52 +0100
+---
+
+
+Review Wizard Status Report for September 2007
+
+
+
+Review Wizard Status Report for September 2007
+==============================================
+
+News
+----
+August 17, 2007 -- Time Series Accepted.
+Announcement: <https://lists.boost.org/boost-announce/2007/08/0142.php>
+July 24, 2007 -- Boost Version 1.34.1 Released.
+This is a bug fix release addressing many problems with
+ the 1.34.0 release. Announcement: <http://svn.boost.org/trac/boost/query?status=closed&milestone=Boost+1.34.1>
+
+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
+-------------
+
+
+* Exception
+* Finite State Machines
+* Floating Point Utilities
+* Switch
+* Property Map (fast-track)
+* Graph (fast-track)
+
+---
+
+
+### Exception
+
+
+| Author: | Emil Dotchevski |
+| Review Manager: | Need Volunteer |
+| Download: | <http://www.revergestudios.com/boost-exception/boost-exception.zip> |
+| Description: | The purpose of this library is to free
+ designers of exception classes from having to consider
+ what data needs to be stored in exception objects in
+ order for the catch site to be able to make sense of
+ what went wrong.
+When the exception class is used,
+ arbitrary values can be stored in any exception. This
+ can be done directly in the throw-expression, or at a
+ later time as the exception object propagates up the
+ call stack. The ability to add data to any exception
+ object after it has been thrown is important, because
+ often some of the information needed to handle an
+ exception is unavailable at the time of the throw. |
+
+
+### Finite State Machines
+
+
+| Author: | Andrey Semashev |
+| Review Manager: | Martin Vuille |
+| Download: | [Boost Sandbox Vault](http://tinyurl.com/yjozfn) |
+| 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](http://boost-consulting.com/vault/index.php?directory=Math%20-%20Numerics) |
+| 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](http://boost-consulting.com/vault/index.php?action=downloadfile&filename=mcs_units_v0.7.1.zip&directory=Units) |
+| 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](http://svn.boost.org/trac/boost/browser/sandbox/graph-v2/libs/property_map/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.
+ |
+
+
+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.
+
+
+
+
+
+
+
+
+

development/requirements.html

@@ -0,0 +1,961 @@
+---
+title: Boost Library Requirements and Guidelines
+copyright: Beman Dawes, 2003. Rene Rivera, 2015.
+revised: 
+---
+
+
+Boost Library Requirements and Guidelines
+
+
+
+Boost Library Requirements and Guidelines
+=========================================
+
+* [Introduction](#Introduction)
+* [Requirements](#Requirements)
+	+ [License requirements](#License)
+	+ [Portability
+	 requirements](#Portability)
+	+ [Ownership](#Ownership)
+	+ [Organization](#Organization)
+	+ [Integration](#Integration)
+* [Guidelines](#Guidelines)
+	+ [Backwards Compatibility](#Backwards_compatibility)
+	+ [Design and
+	 programming](#Design_and_Programming)
+	+ [Filenames](#Filenames)
+	+ [Naming
+	 consistency](#Naming_consistency)
+	+ [Documentation](#Documentation)
+* [Rationale](#Rationale)
+	+ [Exception-specification
+	 rationale](#Exception-specification)
+	+ [Naming conventions
+	 rationale](#Naming)
+	+ [Source code fonts
+	 rationale](#code_fonts)
+	+ [Tabs rationale](#Tabs)
+	+ [Directory and filename
+	 rationale](#FileNamesRat)
+	+ [ECMAScript/JavaScript
+	 rationale](#JavaScript)
+	+ [Rationale
+	 rationale](#Rationale_rationale)
+	+ [Acknowledgements
+	 rationale](#Acknowledgements)
+
+
+Introduction
+------------
+
+
+This page describes requirements and guidelines for the
+ content of a library submitted to Boost.
+
+
+See the [Boost Library Submission
+ Process](submissions.html) page for a description of the process involved.
+
+
+Requirements
+------------
+
+
+To avoid the frustration and wasted time of a proposed
+ library being rejected, it must meet these requirements:
+
+
+* The license must meet the [license
+ requirements](#License) below. Restricted licenses like the GPL and
+ LGPL are not acceptable.
+* The copyright [ownership](#Ownership) must be
+ clear.
+* The library should be generally useful.
+* The library must meet the [portability requirements](#Portability) below.
+* The library should preferably meet the [organization requirements](#Organization) below. But is
+ only required to meet them after acceptance.
+* The library must come reasonably close to meeting the
+ [Guidelines](#Guidelines) below.
+	+ [Design and
+	 Programming](#Design_and_Programming)
+	+ [Filenames](#Filenames)
+	+ [Documentation](#Documentation)
+* The author must be willing to participate in discussions
+ on the mailing list, and to refine the library
+ accordingly.
+
+
+There's no requirement that an author read the mailing list
+ for a time before making a submission. It has been noted,
+ however, that submissions which begin "I just started to read
+ this mailing list ..." seem to fail, often embarrassingly.
+
+
+### License
+ requirements
+
+
+The preferred way to meet the license requirements is to use
+ the [Boost Software License](../LICENSE_1_0.txt).
+ See [license information](../users/license.html). If
+ for any reason you do not intend to use the Boost Software
+ License, please discuss the issues on the Boost [developers mailing list](../community/groups.html#main)
+ first.
+
+
+The license requirements:
+
+
+* Must be simple to read and understand.
+* Must grant permission without fee to copy, use and modify
+ the software for any use (commercial and
+ non-commercial).
+* Must require that the license appear on all copies of the
+ software source code.
+* Must not require that the license appear with executables
+ or other binary uses of the library.
+* Must not require that the source code be available for
+ execution or other binary uses of the library.
+* May restrict the use of the name and description of the
+ library to the standard version found on the Boost web
+ site.
+
+
+### Portability
+ requirements
+
+
+* A library's interface must portable and not restricted to
+ a particular compiler or operating system.
+* A library's implementation must if possible be portable
+ and not restricted to a particular compiler or operating
+ system. If a portable implementation is not possible,
+ non-portable constructions are acceptable if reasonably easy
+ to port to other environments, and implementations are
+ provided for at least two popular operating systems (such as
+ UNIX and Windows).
+* There is no requirement that a library run on C++
+ compilers which do not conform to the ISO standard.
+* There is no requirement that a library run on any
+ particular C++ compiler. Boost contributors often try to
+ ensure their libraries work with popular compilers. The
+ boost/config.hpp [configuration
+ header](../doc/libs/release/libs/config/config.htm) is the preferred mechanism for working around
+ compiler deficiencies.
+
+
+Since there is no absolute way to prove portability, many
+ boost submissions demonstrate practical portability by
+ compiling and executing correctly with two different C++
+ compilers, often under different operating systems. Otherwise
+ reviewers may disbelieve that porting is in fact practical.
+
+
+### Ownership
+
+
+Are you sure you own the library you are thinking of
+ submitting? "How to Copyright Software" by MJ Salone, Nolo
+ Press, 1990 says:
+> 
+> Doing work on your own time that is very similar to
+>  programming you do for your employer on company time can
+>  raise nasty legal problems. In this situation, it's best to
+>  get a written release from your employer in advance.
+> 
+> 
+> 
+
+
+Place a copyright notice in all the important files you
+ submit. Boost won't accept libraries without clear copyright
+ information.
+
+
+### Organization
+
+
+The quality of the Boost libraries is not just about the
+ APIs and code design. But also about presenting a consistent
+ view to users of the libraries as a whole. Upon acceptance
+ libraries must adhere to this directory and file structure:
+
+
+ Boost standard library organization
+ | Sub-directory or file | Contents | Required |
+| --- | --- | --- |
+| `build` | Library build files such as a Jamfile, IDE projects,
+ Makefiles, Cmake files, etc. | Required if the library has sources to build. |
+| `config` | Files used for build-time configuration checks. This
+ directory may contain source files and build system
+ scripts to be used when building the library, tests or
+ examples to check if the target system satisfies certain
+ conditions. For example, a check may test if the compiler
+ implements a certain feature, or if the target system
+ supports a certain API. | Optional. |
+| `doc` | Sources to build with and built documentation for the
+ library. If the library needs to build documentation from
+ non-HTML files this location must be buildable with Boost
+ Build. | Required for all libraries. |
+| `doc/html` | Documentation (HTML) files. | Required for all libraries with pregenerated
+ documentation. And generated documentation must be
+ generated here. |
+| `example` | Sample program files. | Required if library has sample files. Which is highly
+ recommended. |
+| `index.html` | Redirection to HTML documentation. See ["Redirection"](#Redirection) for a template for this
+ file. | Required for all libraries. |
+| `include/boost/*library*` | Header files for the library. | Required for all libraries. |
+| `meta` | Meta-data about the library. | Required for all libraries. |
+| `meta/libraries.json` | [A JSON file containing
+ information about the library](library_metadata.html "Library Metadata File Format") used to generate
+ website and documentation for the Boost C++ Libraries
+ collection. | Required for all libraries. |
+| `meta/explicit-failures-markup.xml` | XML file describing expected test failures, used to
+ generate the test report. | Optional |
+| `src` | Source files which must be compiled to build the
+ library. | Required if the library has source files to
+ build. |
+| `test` | Regression or other test programs or scripts. This is
+ the *only* location considered for automated
+ testing. If you have additional locations that need to be
+ part of automated testing it is required that this
+ location refer to the additional test locations. | Required for all libraries. |
+| `tools` | Tools used, or offered, by the library. The structure
+ within this is up to the library, but it's recommended to
+ use similar structure as a regular Boost library or
+ tool. | Required for libraries that have runable tools. |
+
+
+### Integration
+
+
+Once a library is accepted as part of the Boost C++
+ Libraries it is required that it integrate properly into the
+ development, testing, documentation, and release processes.
+ This integration increases the eventual quality of all the
+ libraries and is integral to the expected quality of the whole
+ of the Boost C++ Libraries from users. In addition to the
+ [organization requirements](#Organization) above the
+ following integration is required:
+
+
+#### Building Sources
+
+
+The library needs to provide a Boost Build project that the
+ user, and the top level Boost project, can use to build the
+ library if it has sources to build. The Jamfile for the source
+ build needs to minimally declare the project, the library
+ target(s), and register the target(s) for installation. For
+ example:
+```
+
+project boost/my\_lib ;
+
+lib boost\_my\_lib : a.cpp ;
+
+boost-install boost\_my\_lib ;
+
+```
+
+#### Testing
+
+
+The library needs to provide a Boost Build project that the
+ user, and the root Boost test script, can use to build and run
+ the tests for the library. The testing build project must
+ reside in the project-root/test directory and must be
+ buildable from this or another directory (for example, b2
+ libs/*library*/test from the Boost root must
+ work.)
+
+
+An example test/Jamfile is given below:
+```
+
+import testing ;
+
+run default\_constructor.cpp ;
+run copy\_constructor.cpp ;
+compile nested\_value\_type.cpp ;
+compile-fail invalid\_conversion\_1.cpp ;
+
+```
+
+*WARNING:* This is the only location considered for
+ testing by the top level testing script. If you want to test
+ additional locations you must declare such that they are built
+ as dependencies or by using build-project.
+
+
+If the library requires a level of C++ conformance that
+ precludes certain compilers or configurations from working,
+ it's possible (and recommended) to declare these requirements
+ in the test Jamfile so that the tests aren't run, to
+ conserve test resources, as given in the example below:
+```
+
+import testing ;
+import ../../config/checks/config : requires ;
+
+project : requirements [ requires cxx11\_variadic\_templates cxx11\_template\_aliases ] ;
+
+run cpp11\_test.cpp ;
+
+```
+
+For more information, see the [documentation
+ of Boost.Config](../libs/config/doc/html/boost_config/build_config.html).
+
+
+#### Building Documentation
+
+
+The library needs to provide a Boost Build project for
+ building the documentation for the library. The
+ project-root/doc project is the only location refered
+ to by the top level documentation build scripts and the release
+ building scripts. The documentation build project must have the
+ following two features:
+
+
+1. Define a boostdoc target. This target should
+ likely be an alias that looks roughly like:  
+
+
+```
+
+alias boostdoc : my\_boostbook\_target
+    : : : <implicit-dependency>my\_boostbook\_target ;
+
+```
+But if your project doesn't integrate into the global documentation
+book you can use an empty alias like:  
+
+
+```
+
+alias boostdoc ;
+
+```
+2. The project must default to building standalone
+ documentation if it has any. The release scripts build this
+ default so as to guarantee all projects have up to date
+ documentation.
+
+
+Guidelines
+----------
+
+
+Please use these guidelines as a checklist for preparing the
+ content a library submission. Not every guideline applies to
+ every library, but a reasonable effort to comply is
+ expected.
+
+
+### Backwards Compatibility
+ Boost libraries generally have a large and diverse user base.
+ To ensure successful transitions from old APIs to newer APIs
+ under those circumstances, library authors are encouraged to
+ follow a few guidelines when introducing breaking changes in
+ their library:
+
+ 1. Non-breaking changes can be done without restriction.
+2. Small breaking changes can be made, but users should be
+ given notice a few releases before the change is published.
+ Most breaking changes fall into this category.
+3. For large breaking changes with a migration path from
+ the old API to the new API (for example boost::filesystem
+ v2 to v3), the new API should be introduced in a separate
+ directory/namespace, and users should be noticed and given
+ a few releases to move over. The old API can be removed after
+ some time.
+4. For large breaking changes without a migration path
+ (for example boost::spirit v2 to v3), the new API
+ should be provided in a separate directory/namespace, and the
+ old API should be preserved (because there's no migration path).
+ Removing the API should be considered the same as removing a
+ Boost library, which can be done but needs a more extensive
+ deprecation period.
+5. Large breaking changes that are equivalent to a redesign or
+ rewrite of the library should be treated as a new library
+ and a formal review (or at least a mini review) is encouraged.
+
+
+### Design and Programming
+
+
+Aim first for clarity and correctness; optimization should
+ be only a secondary concern in most Boost libraries.
+
+
+Aim for ISO Standard C++. Than means making effective use of
+ the standard features of the language, and avoiding
+ non-standard compiler extensions. It also means using the C++
+ Standard Library where applicable.
+
+
+Headers should be good neighbors. See the [header policy](./header.html). See [Naming consistency](#Naming_consistency).
+
+
+Follow quality programming practices. See, for example,
+ "Effective C++" 2nd Edition, and "More Effective C++", both by
+ Scott Meyers, published by Addison Wesley.
+
+
+Use the C++ Standard Library or other Boost libraries, but
+ only when the benefits outweigh the costs. Do not use libraries
+ other than the C++ Standard Library or Boost. See [Library reuse](./reuse.html).
+
+
+Read [Implementation
+ Variation](../community/implementation_variations.html) to see how to supply performance, platform, or
+ other implementation variations.
+
+
+Browse through [the
+ Best Practices Handbook](https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook) for ideas and links to source code
+ in existing Boost libraries.
+
+
+Read the [guidelines
+ for libraries with separate source](./separate_compilation.html) to see how to ensure
+ that compiled link libraries meet user expectations.
+
+
+Use the naming conventions of the C++ Standard Library (See
+ [Naming conventions rationale](#Naming)):
+
+
+* Names (except as noted below) should be all lowercase,
+ with words separated by underscores.
+* Acronyms should be treated as ordinary names (e.g.
+ `xml_parser` instead of
+ `XML_parser`).
+* Template parameter names begin with an uppercase
+ letter.
+* Macro (gasp!) names all uppercase and begin with
+ BOOST\_.
+
+
+Choose meaningful names - explicit is better than implicit,
+ and readability counts. There is a strong preference for clear
+ and descriptive names, even if lengthy.
+
+
+Use exceptions to report errors where appropriate, and write
+ code that is safe in the face of exceptions.
+
+
+Avoid exception-specifications. See [exception-specification
+ rationale](#Exception-specification).
+
+
+Provide sample programs or confidence tests so potential
+ users can see how to use your library.
+
+
+Provide a regression test program or programs which follow
+ the [Test Policies and Protocols](./test.html).
+
+
+Although some boost members use proportional fonts, tabs,
+ and unrestricted line lengths in their own code, boost's widely
+ distributed source code should follow more conservative
+ guidelines:
+
+
+* Use fixed-width fonts. See [fonts
+ rationale](#code_fonts).
+* Use spaces rather than tabs. See [tabs
+ rationale](#Tabs).
+* Limit line lengths to 80 characters.
+
+
+End all documentation files (HTML or otherwise) with a
+ copyright message and a licensing message. See the [license information](../users/license.html) page for the
+ preferred form.
+
+
+Begin all source files (including programs, headers,
+ scripts, etc.) with:
+
+
+* A comment line describing the contents of the file.
+* Comments describing copyright and licensing: again, the
+ preferred form is indicated in the [license information](../users/license.html) page
+* Note that developers are allowed to provide a copy of
+ the license text in `LICENSE_1_0.txt`,
+ `LICENSE.txt` or `LICENSE`
+ file within repositories of their libraries.
+* A comment line referencing your library on the Boost web
+ site. For example:
+ 
+```
+
+// See https://www.boost.org/libs/foo for library home page.
+
+```
+
+Where `foo` is the directory name (see below)
+ for the library. As well as aiding users who come across a
+ Boost file detached from its documentation, some of Boost's
+ automatic tools depend on this comment to identify which
+ library header files belong to.
+
+
+**Assertions:** If you want to add runtime
+ assertions to your code (you should!), avoid C's
+ `assert` macro and use Boost's
+ `BOOST_ASSERT` macro (in
+ `boost/assert.hpp` ) instead. It is more
+ configurable. Use `BOOST_ASSERT` in public headers
+ and in library source code (for separately compiled libraries).
+ Use of C's `assert` macro is ok in examples and in
+ documentation.
+
+
+Make sure your code compiles in the presence of the
+ `min()` and `max()` macros. Some platform
+ headers define `min()` and `max()` macros
+ which cause some common C++ constructs to fail to compile. Some
+ simple tricks can protect your code from inappropriate macro
+ substitution:
+
+
+* If you want to call `std::min()` or
+ `std::max()`:
+	+ If you do not require argument-dependent look-up, use
+	 `(std::min)(a,b)`.
+	+ If you do require argument-dependent look-up, you
+	 should:
+		- `#include
+		 <boost/config.hpp>`
+		- Use `BOOST_USING_STD_MIN();` to bring
+		 `std::min()` into the current scope.
+		- Use `min BOOST_PREVENT_MACRO_SUBSTITUTION
+		 (a,b);` to make an argument-dependent call to
+		 `min(a,b)`.
+* If you want to call
+ `std::numeric_limits<int>::max()`, use
+ `(std::numeric_limits<int>::max)()`
+ instead.
+* If you want to call a `min()` or
+ `max()` member function, instead to doing
+ `obj.min()`, use `(obj.min)()`.
+* If you want to declare or define a function or a member
+ function named `min` or `max`, then you
+ must use the `BOOST_PREVENT_MACRO_SUBSTITUTION`
+ macro. Instead of writing `int min() { return 0;
+ }` you should write `int min
+ BOOST_PREVENT_MACRO_SUBSTITUTION () { return 0; }` This
+ is true regardless if the function is a free (namespace
+ scope) function, a member function or a static member
+ function, and it applies for the function declaration as well
+ as for the function definition.
+
+
+### 
+Filenames
+
+
+Naming requirements ensure that file and directory names are
+ relatively portable, including to ISO 9660:1999 (with
+ extensions) and other relatively limited file systems.
+ Superscript links are provided to detailed rationale for each
+ choice.
+
+
+* Names must contain only
+ **lowercase**[1](#Filename_rationale_1) ASCII letters
+ (`'a'`-`'z'`), numbers
+ (`'0'`-`'9'`), underscores
+ (`'_'`), hyphens (`'-'`), and periods
+ (`'.'`). Spaces are not allowed[2](#Filename_rationale_2).
+* Directory names must not contain periods
+ (`'.'`)[3](#Filename_Rationale_3).
+* The first and last character of a file name must not be a
+ period (`'.'`)[4](#Filename_rationale_4).
+* The first character of names must not be a hyphen
+ (`'-'`)[5](#Filename_rationale_5).
+* The maximum length of directory and file names is 31
+ characters[6](#Filename_rationale_6).
+* The total path length must not exceed 207
+ characters[7](#Filename_rationale_7).
+
+
+Other conventions ease communication:
+
+
+* Files intended to be processed by a C++ compiler as part
+ of a translation unit should have **a three-letter
+ filename extension ending in "pp"**. Other files
+ should *not* use extensions ending in "pp". This
+ convention makes it easy to identify all of the C++ source in
+ Boost.
+* All libraries have at their highest level a primary
+ directory named for the particular library. See [Naming consistency](#Naming_consistency). The primary
+ directory may have sub-directories.
+
+
+#### Redirection
+
+
+The primary directory should always contain a file named
+ index.html. Authors have requested this so that they can
+ publish URL's in the form
+ *https://www.boost.org/libs/lib-name* with the assurance a
+ documentation reorganization won't invalidate the URL. Boost's
+ internal tools are also simplified by knowing that a library's
+ documentation is always reachable via the simplified URL.
+
+
+The primary directory `index.html` file should
+ just do an automatic redirection to the `doc/html`
+ subdirectory:
+```
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
+<head>
+  <title>Boost.Name Documentation</title>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+  <meta http-equiv="refresh" content="0; URL=doc/html/index.html" />
+</head>
+
+<body>
+  Automatic redirection failed, please go to <a href=
+  "doc/index.html">doc/index.html</a>
+</body>
+</html>
+
+```
+
+### Naming consistency
+
+
+As library developers and users have gained experience with
+ Boost, the following consistent naming approach has come to be
+ viewed as very helpful, particularly for larger libraries that
+ need their own header subdirectories and namespaces.
+
+
+Here is how it works. The library is given a name that
+ describes the contents of the library. Cryptic abbreviations
+ are strongly discouraged. Following the practice of the C++
+ Standard Library, names are usually singular rather than
+ plural. For example, a library dealing with file systems might
+ chose the name "filesystem", but not "filesystems", "fs" or
+ "nicecode".
+
+
+* The library's primary directory (in parent
+ boost-root/libs) is given that same name. For
+ example, boost-root/libs/filesystem.
+* The library's primary header directory (in
+ boost-root/libs/name/include) is given that same
+ name. For example,
+ boost-root/libs/filesystem/boost/filesystem.
+* The library's primary namespace (in parent
+ *::boost*) is given that same name, except when
+ there's a component with that name (e.g.,
+ *boost::tuple*), in which case the namespace name is
+ pluralized. For example, *::boost::filesystem*.
+
+
+When documenting Boost libraries, follow these conventions
+ (see also the following section of this document):
+
+
+* The library name is set in roman type.
+* The library name is capitalized.
+* A period between "Boost" and the library name (e.g.,
+ Boost.Bind) is used if and only if the library name is not
+ followed by the word "library".
+* The word "library" is not part of the library name and is
+ therefore lowercased.
+
+
+Here are a few examples of how to apply these
+ conventions:
+
+
+* Boost.Bind was written by Peter Dimov.
+* The Boost Bind library was written by Peter Dimov.
+* I regularly use Bind, a Boost library written by Peter
+ Dimov.
+
+
+### Documentation
+
+
+Even the simplest library needs some documentation; the
+ amount should be proportional to the need. The documentation
+ should assume the readers have a basic knowledge of C++, but
+ are not necessarily experts.
+
+
+The format for documentation should be HTML, and should not
+ require an advanced browser or server-side extensions. Style
+ sheets are acceptable. ECMAScript/JavaScript is discouraged.
+ The documentation entry point should always be a file named
+ index.html; see [Redirection](#Redirection).
+
+
+There is no single right way to do documentation. HTML
+ documentation is often organized quite differently from
+ traditional printed documents. Task-oriented styles differ from
+ reference oriented styles. In the end, it comes down to the
+ question: Is the documentation sufficient for the mythical
+ "average" C++ programmer to use the library successfully?
+
+
+Appropriate topics for documentation often include:
+
+
+* General introduction to the library. The introduction
+ particularly needs to include:
+	+ A very high-level overview of what the library is
+	 good for, and perhaps what it isn't good for,
+	 understandable even by those with no prior knowledge of
+	 the problem domain.
+	+ The simplest possible ("hello world") example of
+	 using the library.
+* Tutorial covering basic use cases.
+* Reference documentation:
+	+ Description of each class.
+	+ Relationship between classes.
+	+ For each function, as applicable, description,
+	 requirements (preconditions), effects, post-conditions,
+	 returns, and throws.
+	+ Discussion of error detection and recovery
+	 strategy.
+* How to compile and link.
+* How to test.
+* Version or revision history.
+* Rationale for design decisions. See [Rationale rationale](#Rationale).
+* Acknowledgements. See [Acknowledgments rationale.](#Acknowledgements)
+
+
+If you need more help with how to write documentation you
+ can check out the article on [Writing
+ Documentation for Boost](../doc/libs/release/more/writingdoc/index.html).
+
+
+Rationale
+---------
+
+
+Rationale for some of the requirements and guidelines
+ follows.
+
+
+### Exception-specification
+ rationale
+
+
+Exception specifications [ISO 15.4] are sometimes coded to
+ indicate what exceptions may be thrown, or because the
+ programmer hopes they will improve performance. But consider
+ the following member from a smart pointer:
+```
+
+T& operator\*() const throw()  { return \*ptr; }
+
+```
+
+This function calls no other functions; it only manipulates
+ fundamental data types like pointers Therefore, no runtime
+ behavior of the exception-specification can ever be invoked.
+ The function is completely exposed to the compiler; indeed it
+ is declared inline Therefore, a smart compiler can easily
+ deduce that the functions are incapable of throwing exceptions,
+ and make the same optimizations it would have made based on the
+ empty exception-specification. A "dumb" compiler, however, may
+ make all kinds of pessimizations.
+
+
+For example, some compilers turn off inlining if there is an
+ exception-specification. Some compilers add try/catch blocks.
+ Such pessimizations can be a performance disaster which makes
+ the code unusable in practical applications.
+
+
+Although initially appealing, an exception-specification
+ tends to have consequences that require **very**
+ careful thought to understand. The biggest problem with
+ exception-specifications is that programmers use them as though
+ they have the effect the programmer would like, instead of the
+ effect they actually have.
+
+
+A non-inline function is the one place a "throws nothing"
+ exception-specification may have some benefit with some
+ compilers.
+
+
+### Naming conventions
+ rationale
+
+
+The C++ standard committee's Library Working Group discussed
+ this issue in detail, and over a long period of time. The
+ discussion was repeated again in early boost postings. A short
+ summary:
+
+
+* Naming conventions are contentious, and although several
+ are widely used, no one style predominates.
+* Given the intent to propose portions of boost for the
+ next revision of the C++ standard library, boost decided to
+ follow the standard library's conventions.
+* Once a library settles on a particular convention, a vast
+ majority of stakeholders want that style to be consistently
+ used.
+
+
+### Source code fonts
+ rationale
+
+
+Dave Abrahams comments: An important purpose (I daresay the
+ primary purpose) of source code is communication: the
+ documentation of intent. This is a doubly important goal for
+ boost, I think. Using a fixed-width font allows us to
+ communicate with more people, in more ways (diagrams are
+ possible) right there in the source. Code written for
+ fixed-width fonts using spaces will read reasonably well when
+ viewed with a variable-width font, and as far as I can tell
+ every editor supporting variable-width fonts also supports
+ fixed width. I don't think the converse is true.
+
+
+### Tabs rationale
+
+
+Tabs are banned because of the practical problems caused by
+ tabs in multi-developer projects like Boost, rather than any
+ dislike in principle. See [mailing list archives](../community/groups.html#archive).
+ Problems include maintenance of a single source file by
+ programmers using tabs and programmers using spaces, and the
+ difficulty of enforcing a consistent tab policy other than just
+ "no tabs". Discussions concluded that Boost files should either
+ all use tabs, or all use spaces, and thus the decision to stick
+ with spaces for indentation.
+
+
+### Directory and
+ File Names rationale
+
+
+1. Some legacy file systems require
+ single-case names. Single-case names eliminate casing mistakes
+ when moving from case-insensitive to case-sensitive file
+ systems.
+
+
+2. This is the lowercase portion of
+ the POSIX portable filename character set. To quote the POSIX
+ standard, "Filenames should be constructed from the portable
+ filename character set because the use of other characters can
+ be confusing or ambiguous in certain contexts."
+
+
+3. Strict implementations of ISO
+ 9660:1999 and some legacy operating systems prohibit dots in
+ directory names. The need for this restriction is fading, and
+ it will probably be removed fairly soon.
+
+
+4. POSIX has special rules for names
+ beginning with a period. Windows prohibits names ending in a
+ period.
+
+
+5. Would be too confusing or
+ ambiguous in certain contexts.
+
+
+6. We had to draw the line
+ somewhere, and so the limit imposed by a now obsolete Apple
+ file system was chosen years ago. It still seems a reasonable
+ limit to aid human comprehension.
+
+
+7. ISO 9660:1999.
+
+
+### ECMAScript/JavaScript rationale
+
+
+Before the 1.29.0 release, two Boost libraries added
+ ECMAScript/JavaScript documentation. Controversy followed (see
+ [mailing list
+ archives](../community/groups.html#archive)), and the developers were asked to remove the
+ ECMAScript/JavaScript. Reasons given for banning included:
+
+
+* Incompatible with some older browsers and some text based
+ browsers.
+* Makes printing docs pages difficult.
+* Often results in really bad user interface design.
+* "It's just annoying in general."
+* Would require Boost to test web pages for
+ ECMAScript/JavaScript compliance.
+* Makes docs maintenance by other than the original
+ developer more difficult.
+
+
+Please conside those reasons if you decide that JavaScript
+ is something you must use. In particular please keep in mind
+ that the Boost community is not responsible for testing your
+ use of JavaScript. And hence it is up to you to ensure that the
+ above issues are fully resolved in your use case.
+
+
+ECMAScript/JavaScript use is allowed but discouraged for the
+ reasons above.
+
+
+### Rationale rationale
+
+
+Rationale is defined as "The fundamental reasons for
+ something; basis" by the American Heritage Dictionary.
+
+
+Beman Dawes comments: Failure to supply contemporaneous
+ rationale for design decisions is a major defect in many
+ software projects. Lack of accurate rationale causes issues to
+ be revisited endlessly, causes maintenance bugs when a
+ maintainer changes something without realizing it was done a
+ certain way for some purpose, and shortens the useful lifetime
+ of software.
+
+
+Rationale is fairly easy to provide at the time decisions
+ are made, but very hard to accurately recover even a short time
+ later.
+
+
+### Acknowledgements rationale
+
+
+As a library matures, it almost always accumulates
+ improvements suggested to the authors by other boost members.
+ It is a part of the culture of boost.org to acknowledge such
+ contributions, identifying the person making the suggestion.
+ Major contributions are usually acknowledged in the
+ documentation, while minor fixes are often mentioned in
+ comments within the code itself.
+
+
+
+
+
+
+

development/reuse.html

@@ -0,0 +1,87 @@
+---
+title: Boost Library Reuse
+copyright: Beman Dawes 2000.
+revised: 2007-10-22 22:55:52 +0100
+---
+
+
+Boost Library Reuse
+
+
+
+Boost Library reuse: cost versus benefit trade-offs
+===================================================
+
+A Boost library **should not** use libraries
+ other than Boost or the C++ Standard Library.
+
+
+A Boost library **should** use other Boost
+ Libraries or the C++ Standard Library, but only when the
+ benefits outweigh the costs.
+
+
+The benefits of using components from other libraries may
+ include clearer, more understandable code, reduced development
+ and maintenance costs, and the assurance which comes from
+ reusing well-known and trusted building blocks.
+
+
+The costs may include undesirable coupling between
+ components, and added compilation and runtime costs. If the
+ interface to the additional component is complex, using it may
+ make code less readable, and thus actually increase development
+ and maintenance costs.
+
+
+Negative effects of coupling become obvious when one library
+ uses a second library which uses a third, and so on. The worst
+ form of coupling requires the user understand each of the
+ coupled libraries. Coupling may also reduce the portability of
+ a library - even in case when all used libraries are
+ self-sufficient (see example of questionable usage of
+ <iostream> library below).
+
+
+**Example where another boost component should
+ certainly be used:** boost::noncopyable (in [boost/utility.hpp](/doc/libs/release/boost/utility.hpp))
+ has considerable benefits; it simplifies code, improves
+ readability, and signals intent. Costs are low as coupling is
+ limited; noncopyable itself uses no other classes and its
+ header includes only the lightweight headers
+ <boost/config.hpp> and <cstddef>. There are no
+ runtime costs at all. With costs so low and benefits so high,
+ other boost libraries should use boost::noncopyable when the
+ need arises except in exceptional circumstances.
+
+
+**Example where a standard library component might
+ possibly be used:** Providing diagnostic output as a
+ debugging aid can be a nice feature for a library. Yet using
+ Standard Library <iostream> can involve a lot of
+ additional cost, particularly if <iostream> is unlikely
+ to be used elsewhere in the application. In certain GUI or
+ embedded applications, coupling to <iostream> would be a
+ disqualification. Consider redesign of the boost library in
+ question so that the user supplies the diagnostic output
+ mechanism.
+
+
+**Example where another boost component should not be
+ used:** The boost dir\_it library has considerable
+ coupling and runtime costs, not to mention portability issues
+ for unsupported operating systems. While completely appropriate
+ when directory iteration is required, it would not be
+ reasonable for another boost library to use dir\_it just to
+ check that a file is available before opening. C++ Standard
+ Library file open functionality does this at lower cost. Don't
+ use dir\_it just for the sake of using a boost library.
+
+
+
+
+
+
+
+
+

development/running_regression_tests.html

@@ -0,0 +1,299 @@
+---
+title: Running Boost Regression Tests
+copyright: Rene Rivera 2007. MetaCommunications, Inc. 2004-2007.
+revised: 
+---
+
+
+Running Boost Regression Tests
+
+
+
+Running Boost Regression Tests
+==============================
+
+Running Regression Tests Locally
+--------------------------------
+
+***It's easy to run regression tests on your Boost
+ clone.***
+
+
+To run a library's regression tests, run Boost's
+ [b2](/build/) utility from the
+ *<boost-root>*/libs/*<library>*/test directory. To run a
+ single test, specify its name (as found in 
+ *<boost-root>*/libs/*<library>*/test/Jamfile.v2) on the
+ command line.
+
+
+See the [Getting
+ Started guide](/doc/libs/release/more/getting_started/index.html) for help building or downloading
+ bjam for your platform, and navigating your Boost
+ distribution.
+
+
+To run every library's regression tests, run b2
+ from *<boost-root>*/status directory.
+
+
+To run Boost.Build's regression tests, run "python
+ test\_all.py" from *<boost-root>*/tools/build/v2/test
+ directory. (Python 2.3 ≤ version < 3.0 required.)
+
+Running Boost's Automated Regression and Reporting
+--------------------------------------------------
+
+This runs all Boost regression tests and reports the results back to
+ the Boost community.
+
+
+### Requirements
+
+
+* Python (2.3 ≤ version < 3.0).
+* Git (recent version).
+* At least 5 gigabytes of disk space per compiler to be
+ tested.
+
+
+### Step by step instructions
+
+
+1. Create a new directory for the branch you want to
+ test.
+2. Download the [run.py](https://raw.githubusercontent.com/boostorg/regression/develop/testing/src/run.py) script into that directory:
+
+> 
+> 1. Open [run.py](https://raw.githubusercontent.com/boostorg/regression/develop/testing/src/run.py) script in your browser.
+> 2. Click the ***Raw*** button.
+> 3. Save as run.py in the directory you just created.
+> 
+> 
+> 
+
+4. Run "`python run.py options... [commands]`"
+ **with these three required options**, plus any others you wish to employ:
+
+
+	* --runner= - Your choice of name that
+	 identifies your results in the reports [1](#runnerid1), [2](#runnerid2).
+	* --toolsets= - The toolset(s) you want to test
+	 with [3](#toolsets).
+	* --tag= - The tag (i.e. branch) you want to test.
+	 The only tags that currently make sense are
+	 develop and master.For example:
+
+python run.py --runner=Metacomm
+ --toolsets=gcc-4.2.1,msvc-8.0 --tag=develop
+
+
+**Note**: If you are behind a firewall/proxy
+ server, everything should still "just work". In the rare cases
+ when it doesn't, you can explicitly specify the proxy server
+ parameters through the --proxy option, e.g.:
+```
+python run.py ... **--proxy=http://www.someproxy.com:3128**
+
+```
+
+### Options
+```
+commands: cleanup, collect-logs, get-source, get-tools, patch, regression,
+setup, show-revision, test, test-boost-build, test-clean, test-process, test-
+run, update-source, upload-logs
+
+Options:
+  -h, --help            show this help message and exit
+  --runner=RUNNER       runner ID (e.g. 'Metacomm')
+  --comment=COMMENT     an HTML comment file to be inserted in the reports
+  --tag=TAG             the tag for the results
+  --toolsets=TOOLSETS   comma-separated list of toolsets to test with
+  --libraries=LIBRARIES
+                        comma separated list of libraries to test
+  --incremental         do incremental run (do not remove previous binaries)
+  --timeout=TIMEOUT     specifies the timeout, in minutes, for a single test
+                        run/compilation
+  --bjam-options=BJAM\_OPTIONS
+                        options to pass to the regression test
+  --bjam-toolset=BJAM\_TOOLSET
+                        bootstrap toolset for 'bjam' executable
+  --pjl-toolset=PJL\_TOOLSET
+                        bootstrap toolset for 'process\_jam\_log' executable
+  --platform=PLATFORM   
+  --user=USER           Boost SVN user ID
+  --local=LOCAL         the name of the boost tarball
+  --force-update        do an SVN update (if applicable) instead of a clean
+                        checkout, even when performing a full run
+  --have-source         do neither a tarball download nor an SVN update; used
+                        primarily for testing script changes
+  --ftp=FTP             FTP URL to upload results to.
+  --proxy=PROXY         HTTP proxy server address and port
+                        (e.g.'http://www.someproxy.com:3128')
+  --ftp-proxy=FTP\_PROXY
+                        FTP proxy server (e.g. 'ftpproxy')
+  --dart-server=DART\_SERVER
+                        the dart server to send results to
+  --debug-level=DEBUG\_LEVEL
+                        debugging level; controls the amount of debugging
+                        output printed
+  --send-bjam-log       send full bjam log of the regression run
+  --mail=MAIL           email address to send run notification to
+  --smtp-login=SMTP\_LOGIN
+                        STMP server address/login information, in the
+                        following form: <user>:<password>@<host>[:<port>]
+  --skip-tests          do not run bjam; used for testing script changes
+
+```
+
+To test develop use "`--tag=develop`",
+ and to test master use
+ "`--tag=master`". Or substitute any Boost
+ tree of your choice.
+
+
+### Details
+
+
+The regression run procedure will:
+
+
+* Download the most recent regression scripts.
+* Download the designated testing tool sources including
+ Boost.Jam, Boost.Build, and the various regression
+ programs.
+* Download the most recent from the [Boost Git Repository](/users/download/#repository)
+ into the subdirectory boost.
+* Build b2 and process\_jam\_log if
+ needed. (process\_jam\_log is a utility, which
+ extracts the test results from the log file produced by
+ Boost.Build).
+* Run regression tests, process and collect the
+ results.
+* Upload the results to a common FTP server.
+
+
+The report merger process running continuously will merge
+ all submitted test runs and publish them at [various locations](testing.html#RegressionTesting).
+
+
+### Advanced use
+
+
+### Providing detailed information about your environment
+
+
+Once you have your regression results displayed in the
+ Boost-wide reports, you may consider providing a bit more
+ information about yourself and your test environment. This
+ additional information will be presented in the reports on a
+ page associated with your runner ID.
+
+
+By default, the page's content is just a single line coming
+ from the comment.html file in your run.py
+ directory, specifying the tested platform. You can put online a
+ more detailed description of your environment, such as your
+ hardware configuration, compiler builds, and test schedule, by
+ simply altering the file's content. Also, please consider
+ providing your name and email address for cases where Boost
+ developers have questions specific to your particular set of
+ results.
+
+
+### Incremental runs
+
+
+You can run run.py in [incremental mode](#incremental) by simply passing it an
+ identically named command-line flag:
+```
+python run.py ... **--incremental**
+
+```
+
+### Patching Boost sources
+
+
+You might encounter an occasional need to make local
+ modifications to the Boost codebase before running the tests,
+ without disturbing the automatic nature of the regression
+ process. To implement this under regression.py:
+
+
+1. Codify applying the desired modifications to the sources
+ located in the ./boost\_root subdirectory in a single
+ executable script named patch\_boost
+ (patch\_boost.bat on Windows).
+2. Place the script in the run.py directory.
+
+
+The driver will check for the existence of the
+ patch\_boost script, and, if found, execute it after
+ obtaining the Boost sources.
+
+
+### Feedback
+
+
+Please send all comments/suggestions regarding this document
+ and the testing procedure itself to the [Boost Testing list](/community/groups.html#testing).
+
+
+### Notes
+
+
+[1] If you are
+ running regressions interlacingly with a different set of
+ compilers (e.g. for Intel in the morning and GCC at the end of
+ the day), you need to provide a *different* runner id
+ for each of these runs, e.g. your\_name-intel, and
+ your\_name-gcc.
+
+
+[2] The limitations
+ of the reports' format/medium impose a direct dependency
+ between the number of compilers you are testing with and the
+ amount of space available for your runner id. If you are
+ running regressions for a single compiler, please make sure to
+ choose a short enough id that does not significantly disturb
+ the reports' layout. You can also use spaces in the runner ID
+ to allow the reports to wrap the name to fit.
+
+
+[3] If
+ --toolsets option is not provided, the script will try
+ to use the platform's default toolset (gcc for most
+ Unix-based systems).
+
+
+[4] By default,
+ the script runs in what is known as *full mode*: on each
+ run.py invocation all the files that were left in
+ place by the previous run — including the binaries for
+ the successfully built tests and libraries — are deleted,
+ and everything is rebuilt once again from scratch. By contrast,
+ in *incremental mode* the already existing binaries are
+ left intact, and only the tests and libraries which source
+ files has changed since the previous run are re-built and
+ re-tested.
+
+
+The main advantage of incremental runs is a significantly
+ shorter turnaround time, but unfortunately they don't always
+ produce reliable results. Some type of changes to the codebase
+ (changes to the b2 testing subsystem in particular) often
+ require switching to a full mode for one cycle in order to
+ produce trustworthy reports.
+
+
+As a general guideline, if you can afford it, testing in
+ full mode is preferable.
+
+
+
+
+
+
+
+
+

development/separate_compilation.html

@@ -0,0 +1,536 @@
+---
+title: Guidelines for Authors of Boost Libraries Containing Separate  Source
+copyright: John Maddock 1998.
+revised: 2007-10-22 22:55:52 +0100
+---
+
+
+Guidelines for Authors of Boost Libraries Containing Separate
+ Source
+
+
+
+Guidelines for Authors of Boost Libraries Containing
+ Separate Source
+=====================================================================
+
+These guidelines are designed for the authors of Boost
+ libraries which have separate source that need compiling in
+ order to use the library. Throughout, this guide refers to a
+ fictitious "whatever" library, so replace all occurrences of
+ "whatever" or "WHATEVER" with your own library's name when
+ copying the examples.
+
+
+Contents
+--------
+[Changes Affecting Source
+ Code](#source_changes)
+
+
+[Preventing Compiler ABI
+ Clashes](#abi)
+[Static or Dymanic
+ Libraries](#static_or_dynamic)
+[Supporting Windows Dll's](#dlls)
+[Automatic Library Selection and
+ Linking with auto\_link.hpp](#auto-link)
+
+
+[Changes Affecting the Build
+ System](#build_changes)
+
+
+[Creating the Library
+ Jamfile](#jamfile)
+[Testing Auto-linking](#testing)
+
+
+[Copyright](#copyright)
+
+Changes
+ Affecting Source Code
+------------------------------
+
+
+### Preventing Compiler ABI
+ Clashes
+
+
+There are some compilers (mostly Microsoft Windows compilers
+ again!), which feature a range of compiler switches that alter
+ the ABI of C++ classes and functions. By way of example,
+ consider Borland's compiler which has the following
+ options:
+```
+
+-b    (on or off - effects enum sizes).
+-Vx   (on or off - empty members).
+-Ve   (on or off - empty base classes).
+-aX   (alignment - 5 options).
+-pX   (Calling convention - 4 options).
+-VmX  (member pointer size and layout - 5 options).
+-VC   (on or off, changes name mangling).
+-Vl   (on or off, changes struct layout). 
+
+```
+
+These options are provided in addition to those affecting
+ which runtime library is used (more on which later); the total
+ number of combinations of options can be obtained by
+ multiplying together the individual options above, so that
+ gives 2\*2\*2\*5\*4\*5\*2\*2 = 3200 combinations!
+
+
+The problem is that users often expect to be able to build
+ the Boost libraries and then just link to them and have
+ everything just plain work, no matter what their project
+ settings are. Irrespective of whether this is a reasonable
+ expectation or not, without some means of managing this issue,
+ the user may well find that their program will experience
+ strange and hard to track down crashes at runtime unless the
+ library they link to was built with the same options as their
+ project (changes to the default alignment setting are a prime
+ culprit). One way to manage this is with "prefix and suffix"
+ headers: these headers invoke compiler specific #pragma
+ directives to instruct the compiler that whatever code follows
+ was built (or is to be built) with a specific set of compiler
+ ABI settings.
+
+
+Boost.config provides the macro BOOST\_HAS\_ABI\_HEADERS which
+ is set whenever there are prefix and suffix headers available
+ for the compiler in use, typical usage in a header like
+ this:
+```
+
+#ifndef BOOST\_WHATEVER\_HPP
+#define BOOST\_WHATEVER\_HPP
+
+#include <boost/config.hpp>
+
+// this must occur after all of the includes and before any code appears:
+#ifdef BOOST\_HAS\_ABI\_HEADERS
+#  include BOOST\_ABI\_PREFIX
+#endif
+//
+// this header declares one class, and one function by way of examples:
+//
+class whatever
+{
+   // details.
+};
+
+whatever get\_whatever();
+
+// the suffix header occurs after all of our code:
+#ifdef BOOST\_HAS\_ABI\_HEADERS
+#  include BOOST\_ABI\_SUFFIX
+#endif
+
+#endif
+
+```
+
+You can include this code in your library source files as
+ well if you want, although you probably shouldn't need to:
+
+
+* If you *don't* use these in the library source
+ files (but do in your library's headers) and the user
+ attempts to compile the library source with a non-default ABI
+ setting, then they will get compiler errors if there are any
+ conflicts.
+* If you *do* include them in both the library's
+ headers and the library source files, then the code should
+ always compile no matter what the compiler settings used,
+ although the result might not match what the user was
+ expecting: since we've forced the ABI back into default
+ mode.
+
+
+#### Rationale:
+
+
+Without some means of managing this issue, users often
+ report bugs along the line of "Your silly library always
+ crashes when I try and call it" and so on. These issues can be
+ extremely difficult and time consuming to track down, only to
+ discover in the end that it's a compiler setting that's changed
+ the ABI of the class and/or function types of the program
+ compared to those in the pre-compiled library. The use of
+ prefix/suffix headers can minimize this problem, although
+ probably not remove it completely.
+
+
+##### Counter Argument #1:
+
+
+Trust the user, if they want 13-byte alignment (!) let them
+ have it.
+
+
+##### Counter Argument #2:
+
+
+Prefix/suffix headers have a tendency to "spread" to other
+ boost libraries - for example if boost::shared\_ptr<>
+ forms part of your class's ABI, then including prefix/suffix
+ headers in your code will be of no use unless shared\_ptr.hpp
+ also uses them. Authors of header-only boost libraries may not
+ be so keen on this solution - with some justification - since
+ they don't face the same problem.
+
+
+### Static or Dynamic Libraries
+
+
+When the users runtime is dynamically linked the Boost
+ libraries can be built either as dynamic libraries (.so's on
+ Unix platforms, .dll's on Windows) or as static libraries (.a's
+ on Unix, .lib's on Windows). So we have a choice as to which is
+ supported by default:
+
+
+* On Unix platforms it typically makes no difference to the
+ code: the user just selects in their makesfile which library
+ they prefer to link to.
+* On Windows platforms, the code has to be specially
+ annotated to support DLL's, so we need to pick one option as
+ the default and one as an alternative.
+* On Windows platforms, we can inject special code to
+ automatically select which library variant to link against:
+ so again we need to decide which is to be the default (see
+ the section on auto-linking below).
+
+
+The recomendation is to pick static linking by default.
+
+
+#### Rationale:
+
+
+There is no one policy that fits all here.
+
+
+The rationale for the current behaviour was inherited from
+ Boost.Regex (and it's ancestor regex++): this library
+ originally used dynamic linking by default whenever the runtime
+ was dynamic. It's actually safer that way should you be using
+ regex from a dll for example. However, this behavior brought a
+ persistent stream of user complaints: mainly about deployment,
+ all asking if static linking could be the default. After regex
+ changed behavior the complaints stopped, and the author hasn't
+ had one complaint about static linking by default being the
+ wrong choice.
+
+
+Note that other libraries might need to make other choices:
+ for example libraries that are intended to be used to implement
+ dll pluggin's would like need to use dynamic linking in almost
+ all cases.
+
+
+### Supporting Windows Dll's
+
+
+On most Unix-like platforms no special annotations of source
+ code are required in order for that source to be compiled as a
+ shared library because all external symbols are exposed.
+ However the majority of Windows compilers require that symbols
+ that are to be imported or exported from a dll, be prefixed
+ with \_\_declspec(dllimport) or \_\_declspec(dllexport). Without
+ this mangling of source code, it is not possible to correctly
+ build shared libraries on Windows (historical note - originally
+ these declaration modifiers were required on 16-bit Windows
+ where the memory layout for exported classes was different from
+ that of "local" classes - although this is no longer an issue,
+ there is still no way to instruct the linker to "export
+ everything", it also remains to be seen whether 64-bit Windows
+ will resurrect the segmented architecture that led to this
+ problem in the first place. Note also that the mangled names of
+ exported symbols are different from non-exported ones, so
+ \_\_declspec(dllimport) is required in order to link to code
+ within a dll).
+
+
+In order to support the building of shared libraries on MS
+ Windows your code will have to prefix all the symbols that your
+ library exports with a macro (lets call it BOOST\_WHATEVER\_DECL)
+ that your library will define to expand to either
+ \_\_declspec(dllexport) or \_\_declspec(dllimport) or nothing,
+ depending upon how your library is being built or used. Typical
+ usage would look like this:
+```
+
+#ifndef BOOST\_WHATEVER\_HPP
+#define BOOST\_WHATEVER\_HPP
+
+#include <boost/config.hpp>
+
+#ifdef BOOST\_HAS\_DECLSPEC // defined in config system
+// we need to import/export our code only if the user has specifically
+// asked for it by defining either BOOST\_ALL\_DYN\_LINK if they want all boost
+// libraries to be dynamically linked, or BOOST\_WHATEVER\_DYN\_LINK
+// if they want just this one to be dynamically liked:
+#if defined(BOOST\_ALL\_DYN\_LINK) || defined(BOOST\_WHATEVER\_DYN\_LINK)
+// export if this is our own source, otherwise import:
+#ifdef BOOST\_WHATEVER\_SOURCE
+# define BOOST\_WHATEVER\_DECL \_\_declspec(dllexport)
+#else
+# define BOOST\_WHATEVER\_DECL \_\_declspec(dllimport)
+#endif  // BOOST\_WHATEVER\_SOURCE
+#endif  // DYN\_LINK
+#endif  // BOOST\_HAS\_DECLSPEC
+//
+// if BOOST\_WHATEVER\_DECL isn't defined yet define it now:
+#ifndef BOOST\_WHATEVER\_DECL
+#define BOOST\_WHATEVER\_DECL
+#endif
+
+//
+// this header declares one class, and one function by way of examples:
+//
+class BOOST\_WHATEVER\_DECL whatever
+{
+   // details.
+};
+
+BOOST\_WHATEVER\_DECL whatever get\_whatever();
+
+#endif
+
+```
+And then in the source code for this library one would use:
+ 
+```
+
+ 
+// 
+// define BOOST\_WHATEVER SOURCE so that our library's 
+// setup code knows that we are building the library (possibly exporting code), 
+// rather than using it (possibly importing code): 
+// 
+#define BOOST\_WHATEVER\_SOURCE 
+#include <boost/whatever.hpp> 
+
+// class members don't need any further annotation: 
+whatever::whatever() { } 
+// but functions do: 
+BOOST\_WHATEVER\_DECL whatever get\_whatever() 
+{
+   return whatever();
+}
+
+```
+
+#### Importing/exporting dependencies
+
+
+As well as exporting your main classes and functions (those
+ that are actually documented), Microsoft Visual C++ will warn
+ loudly and often if you try to import/export a class whose
+ dependencies are not also exported. Dependencies include: any
+ base classes, any user defined types used as data members, plus
+ all of the dependencies of your dependencies and so on. This
+ causes particular problems when a dependency is a template
+ class, because although it is technically possible to export
+ these, it is not at all easy, especially if the template itself
+ has dependencies which are implementation-specific details. In
+ most cases it's probably better to simply suppress the warnings
+ using:
+```
+
+#ifdef BOOST\_MSVC
+#  pragma warning(push)
+#  pragma warning(disable : 4251 4231 4660)
+#endif
+
+// code here
+
+#ifdef BOOST\_MSVC
+#pragma warning(pop)
+#endif
+
+```
+
+This is safe provided that there are no dependencies that
+ are (template) classes with non-constant static data members,
+ these really do need exporting, otherwise there will be
+ multiple copies of the static data members in the program, and
+ that's really really bad.
+
+
+Historical note: on 16-bit Windows you really did have to
+ export all dependencies or the code wouldn't work, however
+ since the latest Visual Studio .NET supports the import/export
+ of individual member functions, it's a reasonably safe bet that
+ Windows compilers won't do anything nasty - like changing the
+ class's ABI - when importing/exporting a class.
+
+
+#### Rationale:
+
+
+*Why bother - doesn't the import/export mechanism take up
+ more code that the classes themselves?*
+
+
+A good point, and probably true, however there are some
+ circumstances where library code must be placed in a shared
+ library - for example when the application consists of multiple
+ dll's as well as the executable, and more than one those dll's
+ link to the same Boost library - in this case if the library
+ isn't dynamically linked and it contains any global data (even
+ if that data is private to the internals of the library) then
+ really bad things can happen - even without global data, we
+ will still get a code bloating effect. Incidentally, for larger
+ applications, splitting the application into multiple dll's can
+ be highly advantageous - by using Microsoft's "delay load"
+ feature the application will load only those parts it really
+ needs at any one time, giving the impression of a much more
+ responsive and faster-loading application.
+
+
+*Why static linking by default?*
+
+
+In the worked example above, the code assumes that the
+ library will be statically linked unless the user asks
+ otherwise. Most users seem to prefer this (there are no
+ separate dll's to distribute, and the overall distribution size
+ is often significantly smaller this way as well: i.e. you pay
+ for what you use and no more), but this is a subjective call,
+ and some libraries may even only be available in dynamic
+ versions (Boost.threads for example).
+
+
+### Automatic Library
+ Selection and Linking with [auto\_link.hpp](/doc/libs/release/boost/config/auto_link.hpp)
+
+
+Many Windows compilers ship with multiple runtime libraries
+ - for example Microsoft Visual Studio .NET comes with 6
+ versions of the C and C++ runtime. It is essential that the
+ Boost library that the user links to is built against the same
+ C runtime as the program is built against. If that is not the
+ case, then the user will experience linker errors at best, and
+ runtime crashes at worst. The Boost build system manages this
+ by providing different build variants, each of which is build
+ against a different runtime, and gets a slightly different
+ mangled name depending upon which runtime it is built against.
+ For example the regex libraries get named as follows when built
+ with Visual Studio .NET 2003:
+```
+
+boost\_regex-vc71-mt-1\_31.lib
+boost\_regex-vc71-mt-gd-1\_31.lib
+libboost\_regex-vc71-mt-1\_31.lib
+libboost\_regex-vc71-mt-gd-1\_31.lib
+libboost\_regex-vc71-mt-s-1\_31.lib
+libboost\_regex-vc71-mt-sgd-1\_31.lib
+libboost\_regex-vc71-s-1\_31.lib
+libboost\_regex-vc71-sgd-1\_31.lib
+
+```
+
+The difficulty now is selecting which of these the user
+ should link his or her code to.
+
+
+In contrast, most Unix compilers typically only have one
+ runtime (or sometimes two if there is a separate thread safe
+ option). For these systems the only choice in selecting the
+ right library variant is whether they want debugging info, and
+ possibly thread safety.
+
+
+Historically Microsoft Windows compilers have managed this
+ issue by providing a #pragma option that allows the header for
+ a library to automatically select the library to link to. This
+ makes everything automatic and extremely easy for the end user:
+ as soon as they include a header file that has separate source
+ code, the name of the right library build variant gets embedded
+ in the object file, and as long as that library is in the
+ linker search path, it will get pulled in by the linker without
+ any user intervention.
+
+
+Automatic library selection and linking can be enabled for a
+ Boost library by including the header
+ <boost/config/auto\_link.hpp>, after first defining
+ BOOST\_LIB\_NAME and, if applicable, BOOST\_DYN\_LINK.
+```
+
+//
+// Automatically link to the correct build variant where possible. 
+// 
+#if !defined(BOOST\_ALL\_NO\_LIB) && !defined(BOOST\_WHATEVER\_NO\_LIB) && !defined(BOOST\_WHATEVER\_SOURCE)
+//
+// Set the name of our library, this will get undef'ed by auto\_link.hpp
+// once it's done with it:
+//
+#define BOOST\_LIB\_NAME boost\_whatever
+//
+// If we're importing code from a dll, then tell auto\_link.hpp about it:
+//
+#if defined(BOOST\_ALL\_DYN\_LINK) || defined(BOOST\_WHATEVER\_DYN\_LINK)
+#  define BOOST\_DYN\_LINK
+#endif
+//
+// And include the header that does the work:
+//
+#include <boost/config/auto\_link.hpp>
+#endif  // auto-linking disabled
+
+```
+
+The library's user documentation should note that the
+ feature can be disabled by defining either BOOST\_ALL\_NO\_LIB or
+ BOOST\_WHATEVER\_NO\_LIB:
+
+
+If for any reason you need to debug this feature, the header
+ <boost/config/auto\_link.hpp> will output some helpful
+ diagnostic messages if you first define
+ BOOST\_LIB\_DIAGNOSTIC.
+
+
+Changes
+ Affecting the Build System
+-----------------------------------
+
+
+### Creating the library Jamfile
+
+
+The Jamfile for building library "whatever" typically lives
+ in boost-root/libs/whatever/build, the only extra step required
+ is to add a <define> requirement to the library target so
+ that your code knows whether it's building a dll or static
+ library, a typical Jamfile would like like this:
+```
+
+lib boost\_regex : ../src/whatever.cpp : 
+  <link>shared:<define>BOOST\_WHATEVER\_DYN\_LINK=1 ;
+ 
+
+```
+
+### Testing
+ Auto-linking
+
+
+Testing the auto-link feature is somewhat convoluted, and
+ requires access to a compiler that supports the feature: refer
+ to [libs/config/test/link/test/Jamfile.v2](/doc/libs/release/libs/config/test/link/test/Jamfile.v2)
+ for an example.
+
+
+
+
+
+
+
+
+

development/submissions.html

@@ -0,0 +1,344 @@
+---
+title: Boost Library Submission Process
+copyright: Beman Dawes, 2000.
+revised: 
+---
+
+
+Boost Library Submission Process
+
+
+
+Boost Library Submission Process
+================================
+
+This page describes the process a library developer goes
+ through to get a library accepted by Boost.
+
+
+See the [Boost Library
+ Requirements and Guidelines](requirements.html) page for issues of content.
+
+
+### Steps for getting a library accepted by Boost:
+
+
+* [1. Learn about Boost](#Learn)
+* [2. Determine interest](#interest)
+* [3. Start Development](#Development)
+* [4. Refinement](#Refinement)
+* [5. Getting seconded for review](#Seconded)
+* [6. Seek a Review Manager](#Seeking)
+* [7. Formal Review](#Review)
+* [8. Web site posting](#SitePosting)
+* [9. People page](#People)
+* [10. Lifecycle](#Lifecycle)
+
+
+1. Learn about Boost
+--------------------
+
+
+Follow posts on the [main
+ developers mailing list](/community/groups.html#main) for a while, or look through the
+ [archives](/community/groups.html#archive). Explore
+ the [web site](/). Learn the [Requirements](requirements.html). Read the rest of this
+ page to learn about the process. Search the web to get an idea
+ of the commitment required to get a library into Boost.
+ 
+
+
+There is a culture associated with Boost, aimed at
+ encouraging high quality libraries by a process of discussion
+ and refinement. Some libraries get past community review
+ in less than two years from first concept, but most take longer,
+ sometimes a lot longer. Five to ten years to get a library past
+ review and into Boost is not unheard of, and you should prepare
+ yourself for the personal investment required.
+
+
+2. Determine
+ interest
+----------------------
+
+
+While participation in reviews for other submissions is not a
+ prerequisite for submitting a library to Boost, it is highly
+ recommended; it will acquaint you with the process and the
+ emotional demands of a formal review. There's nothing that quite
+ deflates the ego like having brilliant members of the C++
+ community critiquing your work, but, alas, it's worth it!
+
+
+Potential library submitters should be careful to
+ research the prior art before beginning to design a
+ new library. Unfortunately, now and then folks arrive at Boost
+ with a new library into which they have invested many hours, only
+ to find that Boost already has that functionality, and sometimes
+ has had it for years. Candidates should also research libraries being
+ developed by others intended for Boost - if you have an itch
+ to scratch, often so have had others and collaboration
+ developing their library is usually considerably more efficient
+ than going at it alone.
+
+
+Potential library submitters should also be careful to
+ publicise, canvas for, and gauge interest in their library,
+ ideally before beginning it, but certainly before submitting it
+ for review. Even a superbly designed library can fail review if
+ there isn't enough interest in the subject matter; We can only
+ review libraries with enough appeal to form a viable peer
+ review. Ensuring that enough people are interested in your
+ potential library goes a long way to ensure that.
+
+
+There are many places to publicise and canvas for a library.
+ The Boost developers [mailing
+ list](/community/groups.html) ought to be your first stop in gauging interest
+ in a possible new C++ library. Be prepared to pivot your design
+ and focus until your proposed library finds traction. Other
+ places useful for gauging interest in a library might be [Reddit/r/cpp](https://www.reddit.com/r/cpp/).
+
+
+A message to the Boost developers mailing list
+ might be as simple as "Is there any interest in a
+ library which solves Travelling Salesperson problems in linear
+ time?"
+
+
+A bit of further description or snippet of code may be
+ helpful. By the way, the preferred format for messages on the
+ mailing list is plain text; not rich text, HTML, etc.
+
+
+Avoid posting lengthy descriptions, documentation,
+ or code to the mailing list, and, please, no attachments.
+ The best place to provide lengthy material is via. a web link.
+ Project hosting services such as sourceforge, github, google
+ code, and bitbucket serve well for this purpose.
+
+
+3. Start
+ Development
+---------------------
+
+
+If response to an initial query indicates interest, then
+ by all means make your library publicly available if you haven't
+ already done so.
+
+
+Please commit your code to a version control system such as
+ Git, and make your documentation available in HTML format on
+ a public website such as Github. An issue tracker such as the one
+ provided by Github is also highly recommended.
+
+
+Your library should contain material as if it were on the
+ boost.org web site. The closer your library reflects the
+ final directory structure and format of the web site, the
+ better. This makes it possible for reviewers to simply copy
+ your code into the Boost distribution for testing.
+
+
+Please verify that your library compiles and runs under
+ at least two compilers. This flushes out obvious portability
+ problems.
+
+
+It is recommended that you release your code under the Boost
+ Software License; see the [Requirements](requirements.html) page for more
+ information.
+
+
+4. Refinement
+-------------
+
+
+Discuss, refine, rewrite. Repeat until satisfied.
+
+
+The exact details of this process varies a lot. Usually it
+ is public, on the mailing list, but frequently discussion
+ happens in private emails. For some libraries the process is
+ over quickly, but for others it goes on for months. It's
+ often challenging, and sometimes veers into completely
+ unexpected directions.
+
+
+The [archive](/community/groups.html#archive) of
+ past messages is one way to see how this process worked for
+ other Boost libraries.
+
+
+To get an idea of best practices with some samples of script
+ and code in existing Boost libraries, see the
+ [Best Practices Handbook](https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook) on the Boost wiki.
+
+
+5. Getting seconded
+ for review
+-------------------------------
+
+
+When you feel that your library is ready for entry into Boost,
+ you need to find at least one member (but preferably several) of
+ the Boost community who is willing to publicly endorse your
+ library for entry into Boost. A simple method of achieving this
+ is to post to [the Boost
+ developers mailing list](/community/groups.html) a short description of your
+ library, links to its github and documentation, and a request for
+ endorsements.
+
+
+It is expected that those who endorse a library for review
+ will have performed at least a cursory check of the library's
+ suitability for Boost in terms of documentation, fit with
+ the rest of Boost and usefulness. A public endorsement of a
+ library for review means that from an initial glance, they
+ believe that the library has a reasonable chance to be accepted
+ during a formal review. The expectation is that these endorsers
+ will themselves review of the library during formal review
+ period, though this is not binding.
+
+
+Once you have a list of people who have publicly endorsed
+ your library for review, email [the Review Wizards](/community/reviews.html#Wizard)
+ to request that your library be added to [the review queue](/community/review_schedule.html)
+ where the following information will be shown:
+
+
+* Submission
+* Submitter
+* Links to Source (GitHub), Documentation (HTML website)
+ and any Incubator entry
+* Names of members who endorse this submission for review
+* Review Manager
+* Review Dates
+
+
+6. Seek a Review
+ Manager
+-------------------------
+
+
+In order to schedule a formal review, the author must find a
+ capable volunteer to manage the review. This should be someone
+ with knowledge of the library domain, and experience with the
+ review process. See [Formal
+ Review Process](/community/reviews.html) for the responsibilities of the review
+ manager.
+
+
+Authors can find community members interested in managing
+ reviews through discussion of the library on the developer
+ list. If no one steps forward to volunteer to manage the
+ review, it is appropriate to contact an experienced Boost
+ member who showed interest in the library. Be considerate that
+ managing a review is a serious commitment; for this reason,
+ it's better to contact the member off-list.
+
+
+If you cannot find a review manager after 3 weeks using the
+ means above, and your submission is targeting eventual
+ standardization, there is a list of Boost regulars who are also
+ WG21 committee members who have volunteered to act as review
+ managers in such cases. Please try them in the order listed.
+ They are: Zach Laine, Micheal Caisse, Matt Calabrese, Edward
+ Diener, Louis Dionne, Vinnie Falco, Glen Fernandes, and David
+ Sankel.
+
+
+Once a potential review manager has been identified, [contact the
+ review wizards](/community/reviews.html#Wizard) for approval. The wizards approve review
+ managers based on their level of participation in the Boost
+ community.
+
+
+The review wizards will coordinate with both the author and
+ review manager to schedule a date convenient for both.
+
+
+See [Formal Review
+ Process](/community/reviews.html) for details.
+
+
+7. Formal Review
+----------------
+
+
+Before your formal review begins, double-, triple-, and
+ quadruple-check your library. Verify that every code example
+ works, that all unit tests pass on at least two compilers on at
+ least two major operating systems, and run your documentation
+ through a spelling and grammar checker.
+
+
+Please do not modify your library on its master branch
+ during a review. Instead, modify a separate develop branch in
+ response to feedback and reviews. For bigger ticket items of
+ work, open issues on your issue tracker so interested people can
+ track the fixing of specific issues raised.
+
+
+The review manager will consider all the reviews made by
+ members of the community and arrive at a decision on
+ whether your library is rejected, conditionally accepted or
+ unconditionally accepted. They will post a report summarising
+ the decision publicly. If conditions are attached to
+ acceptance, you will need to implement those conditions or
+ else undergo an additional formal review.
+
+
+8. Boost web site
+ posting
+--------------------------
+
+
+Once an accepted library is ready for inclusion on the Boost
+ web site, the submitter is typically given Boost repository
+ write access, and expected to check-in and maintain the library
+ there. Contact the moderators if you need write access or
+ direct use of the repository isn't possible for you.
+
+
+9. People page
+--------------
+
+
+If the boost.org web site doesn't already have your capsule
+ biography and picture (optional, with not-too-serious pictures
+ preferred!), please send them to the Boost webmaster. It is up
+ to you as to whether or not the biography includes your email
+ address or other contact information. The preferred picture
+ format is .jpg, but other common formats are acceptable. The
+ preferred image size is 500x375 but the webmaster has photo
+ editing software and can do the image preparation if
+ necessary.
+
+
+10. Lifecycle
+-------------
+
+
+Libraries are software; they lose their value over time if
+ not maintained. Postings on the Boost developers or users
+ mailing lists can alert you to potential maintenance needs;
+ please plan to maintain your library over time. If you no
+ longer can or wish to maintain your library, please post a
+ message on the Boost developers mailing list asking for a new
+ maintainer to volunteer and then spend the time to help them
+ take over.
+
+
+Orphaned libraries will be put in the care of the [Community
+ Maintenance Team](https://svn.boost.org/trac/boost/wiki/CommunityMaintenance).
+
+
+
+
+
+
+
+
+

development/template/template.html

@@ -0,0 +1,24 @@
+---
+title: Boost C++ Libraries
+copyright: Beman Dawes, David Abrahams, 1998-2005. Rene Rivera 2004-2005.
+revised: 2005-12-17 14:32:46 -0500
+---
+
+
+Boost C++ Libraries
+
+
+
+Boost C++ Libraries
+===================
+
+{stuff}
+
+
+
+
+
+
+
+
+

development/test.html

@@ -0,0 +1,127 @@
+---
+title: Boost Test Policies and Protocols
+copyright: Beman Dawes 2001.
+revised: 
+---
+
+
+Boost Test Policies and Protocols
+
+
+
+Boost Test Policies and Protocols
+=================================
+
+The Boost libraries are intended to be both reliable and
+ portable. Every experienced programmer knows that means each
+ library must be tested against a suitable number of test cases,
+ on a wide range of platforms, and then tested again (regression
+ tested) every time a change is made and before every
+ release.
+
+
+"Quality assurance based on a wide range of targeted tests"
+ as one of the key answers to C.A.R Hoare's question "How did
+ software get so reliable without proof."
+
+
+Regression test
+---------------
+
+
+Boost uses an automatic [regression
+ test suite](/doc/tools/regression/index.html) which generates HTML [compiler status
+ tables](/development/testing.html#RegressionTesting).
+
+
+Test Policy
+-----------
+
+
+### Required
+
+
+* Every Boost library should supply one or more suitable
+ test programs to be exercised by the Boost [regression
+ test suite](/doc/tools/regression/index.html). In addition to the usual compile-link-run
+ tests expecting successful completion, compile-only or
+ compile-and-link-only tests may be performed, and success for
+ the test may be defined as failure of the steps.
+* Test program execution must report errors by returning a
+ non-zero value. They may also write to stdout or stderr, but
+ that output should be relatively brief. Regardless of other
+ output, a non-zero return value is the only way the
+ regression test framework will recognize an error has
+ occurred. Note that test programs to be included in the
+ status tables must compile, link, and run quickly since the
+ tests are executed many, many, times.
+* Libraries with time consuming tests should be divided
+ into a fast-execution basic test program for the status
+ tables, and a separate full-coverage test program for
+ exhaustive test cases. The basic test should concentrate on
+ compilation issues so that the status tables accurately
+ reflect the library's likelihood of correct compilation on a
+ platform.
+* If for any reason the usual test policies do not apply to
+ a particular library, an alternate test strategy must be
+ implemented.
+* A [Jamfile](/doc/tools/regression/index.html#Adding_new_test) to drive the regression tests for the
+ library.
+
+
+### Optional (but highly recommended)
+
+
+The [Boost
+ Test Library](/doc/libs/release/libs/test/index.html) provides many useful components which ease the
+ construction of test programs.
+
+
+* Use the library's [Test Tools](/doc/libs/release/libs/test/doc/html/boost_test/testing_tools.html) for the construction of simple test programs
+ that do not need much structure.
+* Use the library's [Unit
+ Test Framework](/doc/libs/release/libs/test/doc/html/boost_test/tests_organization.html) for the construction of more complex test
+ programs that need to be structured into individual tests and
+ test suites.
+
+
+Suggested Protocol for Fixing Bugs or Adding Features.
+------------------------------------------------------
+
+
+* First, add regression test cases that detects the bug or
+ tests the feature. Sometimes adding one case suggests similar
+ untested cases, and they are added too.
+* Second, for bugs, run the regression test and verify that
+ the bug is now detected.
+* Third, then, and only then, fix the bug or add the
+ feature.
+* Finally, rerun the full regression tests - sometimes the
+ change breaks something else.
+
+
+History
+-------
+
+
+[See
+ Regression Test History](/doc/tools/regression/index.html#History).
+
+
+Acknowledgements
+----------------
+
+
+Written by Beman Dawes. Jens Maurer, Paul Moore, Gary Powell
+ and Jeremy Siek contributed helpful suggestions.
+
+---
+
+
+
+
+
+
+
+
+

development/testing.html

@@ -0,0 +1,144 @@
+---
+title: Testing
+copyright: Rene Rivera 2007.
+revised: 
+---
+
+
+Testing
+
+
+/\*<![CDATA[\*/
+ th.c1 {font-style: italic}
+ /\*]]>\*/
+ 
+
+
+Testing
+=======
+
+* [Regression Tests](#RegressionTesting)
+* [Snapshots](#Snapshots)
+* [Inspection Reports](#Inspection)
+* [More about regression
+ tests](#Introduction)
+
+
+Regression Tests
+----------------
+
+
+A group of volunteers donate CPU cycles and large amounts of
+ disk space to collectively produce the regression testing
+ result tables. Various Boost repository versions are tested for
+ the benefit of library developers and interested users:
+
+| Version | Developers |
+| --- | --- |
+| Develop branch | [Summary](tests/develop/developer/summary.html) | [Unresolved
+ Issues](tests/develop/developer/issues.html) |
+| Master branch | [Summary](tests/master/developer/summary.html) | [Unresolved
+ Issues](tests/master/developer/issues.html) |
+
+
+Snapshots
+---------
+
+
+Snapshots are used for quality control checks.  The
+ Unix tarballs and Windows zipballs are identical except for the
+ line endings exported from Git.
+
+
+Because the snapshots represent work-in-process, they may
+ not be suitable for production use.
+
+| Version | Download | Documentation |
+| --- | --- | --- |
+| Master branch | [Sourceforge](https://sourceforge.net/projects/boost/files/boost/snapshots/master/ "Boost master branch snapshots on sourceforge"), [JFrog.io](https://boostorg.jfrog.io/artifactory/main/master/ "Boost master branch snapshots on JFrog.io"). | [Documentation](/doc/libs/master/ "Boost master branch documentation snapshot") |
+| Develop branch | [Sourceforge](https://sourceforge.net/projects/boost/files/boost/snapshots/develop/ "Boost develop branch snapshots on sourceforge"), [JFrog.io](https://boostorg.jfrog.io/artifactory/main/develop "Boost develop branch snapshots on JFrog.io"). | [Documentation](/doc/libs/develop/ "Boost develop branch documentation snapshot") |
+
+
+The Git master branch can be checked out from <https://github.com/boostorg/boost>.
+
+
+Inspection
+ Reports
+-------------------
+
+
+The Boost snapshots are inspected daily to detect problems
+ such as missing copyrights or licenses. The Boost Inspection
+ Report tells all!
+
+| Version |
+| --- |
+| [Develop
+ branch](http://boost.cowic.de/rc/docs-inspect-develop.html) |
+| [Master
+ branch](http://boost.cowic.de/rc/docs-inspect-master.html) |
+
+
+More about
+ regression tests
+----------------------------
+
+
+Will all Boost libraries work with your compiler? 
+ Unfortunately, the answer is "it depends". See the [regression testing results](#RegressionTesting) to see
+ exactly what works and what doesn't.
+
+
+Boost libraries rely on modern C++ features such as
+ templates and the C++ Standard Library.  Most modern
+ compilers support those major features fairly well. But even
+ today, years after the adoption of the C++ Standard, some
+ compilers still don't support important minor features like
+ partial template specialization.
+
+
+Boost library authors often expend a great deal of effort
+ trying to work around compiler deficiencies. 
+ Nevertheless, some libraries will not compile at all with
+ certain compilers or may have crippled functionality. 
+ Even if the current release of a compiler supports a boost
+ library, older versions of the compiler may not work
+ properly.
+
+
+Boost releases are run through regression tests which
+ automatically generates compiler status tables for various
+ platforms. Unless otherwise indicated, the C++ Standard Library
+ implementation is the one shipped with the compiler.
+
+
+### Warnings:
+
+
+* These tables are not a good indication of a particular
+ compiler's compliance with the C++ Standard.  The Boost
+ libraries often contain workarounds which mask compiler
+ deficiencies.
+* Some regression tests are run only occasionally, and so
+ are relatively out-of-date.  Check the date and revision
+ in the column heading.
+
+
+The development code is being updated several times a day,
+ so it may contain bug fixes, compiler workarounds, new
+ features, and even whole new libraries. It may be unstable,
+ however.
+
+
+A list of some of the organizations helping with testing is
+ listed on the [Acknowledgements
+ page](/community/acknowledgements.html#testing).
+
+
+
+
+
+
+
+
+

development/website_updating.html

@@ -0,0 +1,337 @@
+---
+title: Boost C++ Libraries - Updating Website
+copyright: Rene Rivera 2006-2007.
+revised: 
+---
+
+
+Boost C++ Libraries - Updating Website
+
+
+
+Updating and Editing Website Content
+====================================
+
+* [Getting Content](#GettingContent)
+* [Existing Page](#ExistingPage)
+* [New Page](#NewPage)
+* [Menus, Sidebars, and Index](#Menus)
+* [Feeds](#Feeds)
+* [Local Server](#Local_Server)
+
+
+Getting
+ Content
+----------------
+
+
+The website content lives in the [git repository](https://github.com/boostorg/website/).
+
+
+In progress work is on the `beta` branch, the
+ live website is on the `master` branch. The website
+ is updated automatically from the git repo. If you want to
+ update the website, please create a pull request.
+
+
+Existing
+ Page
+--------------
+
+
+Large sections of the site are automatically generated, this
+ includes the release notes, the news pages and any files in the
+ generated directory. If you wish to edit these, see below.
+
+
+The web content is structured to be as simple as possible to
+ make generic editing possible. At minimum only a text editor
+ and [HTML Tidy](http://tidy.sourceforge.net/) are needed to edit
+ content. The content uses [XHTML 1.0 Strict](http://www.w3.org/TR/xhtml1/) for various
+ reasons, the most important being to increase accessibility and
+ to enforce the separation of style from content. After getting
+ the content you want to edit as above, make the changes you
+ want and run the result through HTML Tidy with these
+ options:
+```
+
+tidy --tidy-mark no -i -wrap 78 -m -asxhtml --merge-divs no --merge-spans no --doctype strict *fname*
+
+```
+
+Running HTML Tidy with a consistent set of options also
+ helps in keeping an accurate change history in the repository.
+ There are [examples](/development/exemplar.html) of
+ the kinds of styles supported either directly or through the
+ use of [class="*value*"] attributes for the
+ various XHTML tags. Please pay attention to any errors and
+ warnings that HTML Tidy mentions and strive to remove all of
+ them.
+
+
+**NOTE:** The options for tidy are for
+ the latest version. In particular the --merge-\*
+ options may not be available in the version that comes as part
+ of many Unix/Linux distributions, and Windows utilities.
+ Removing the unavailable options is possible and will work. But
+ we recommend installing the latest tidy if possible.
+ You can obtain up to date Windows binaries, and sources from
+ the [HTML Tidy Library
+ Project](http://tidy.sourceforge.net/).
+
+
+The pages should be viewable in most browsers. If possible
+ test you changes in as many as possible. Preferably at least
+ two modern browsers if you are on Windows. But if you are on another
+ platform testing with the "default" browser is best.
+ Normally viewing the page in outside of the web server context
+ will only show you the content and part of the footer.
+ This is because the site uses Server Side Includes (SSI)
+ which most browsers will not process. To look at the
+ complete content you will need to either run your own Apache
+ server, or commit the changes and view the changes online
+ at:
+
+| Site | URL | Branch |
+| --- | --- | --- |
+| Beta | <http://beta.boost.org/> | `beta` |
+| This is the experimetal version of the
+ website. Development work should be done here first and
+ then merged to the live website. |
+| Live | <https://www.boost.org/> | `master` |
+| The website the general public will
+ see. |
+
+
+New Page
+--------
+
+
+To make adding new pages easier there is a [template](/development/template/template.html) to get one
+ started. There are also `_template_.html` files in
+ the various site sections which already include the correct
+ sidebar menus. To start, copy the template to the section of
+ the website you want to add to and name the new file with a
+ reasonably clear name. The section is up to you but the
+ intended type of content for each is:
+Introduction
+Content to help new users understand what Boost is for
+ and what it is about. This is the one place where new
+ visitors are going to visit. Directory: /users
+Community
+For users who are interested in participating, or are
+ already participitating, this section describes how the Boost
+ community of users and developers functions. Directory:
+ /community
+Development
+Prospective or existing Boost developers make use of this
+ section to quickly get to the most frequetly used content.
+ This section is intended to hold the references to resources
+ or directly include content that changes frequently. Or
+ content that only pertains to library developers, although it
+ may be of more widespread interest as users become more
+ involved in the Boost community. Directory:
+ /development
+Documentation
+This section organizes documents specific to the Boost
+ libraries. This includes at minimum the library documentation
+ published with each of the Boost releases. Also included is
+ access to the community maintained Wiki. Directory:
+ /doc
+
+To provide the section user interface look and feel there
+ are some changes that need to be done to the template:
+
+
+* Each section has a different CSS style reference
+ included in the head section. This reference needs
+ to change to one of:
+
+
+	+ Introduction:
+	 /style-v2/section-boost.css
+	+ Community:
+	 /style-v2/section-community.css
+	+ Development:
+	 /style-v2/section-development.css
+	+ Support: /style-v2/section-support.css
+	+ Documentation:
+	 /style-v2/section-doc.css
+* Each section displays a different context sensitive
+ sidebar menu through the use of SSI. The reference to the
+ sidebar to display needs to change in the sidebar
+ section to one of:
+
+
+	+ Introduction:
+	 /common/sidebar-boost.html
+	+ Community:
+	 /common/sidebar-community.html
+	+ Development:
+	 /common/sidebar-development.html
+	+ Support: /common/sidebar-support.html
+	+ Documentation: /common/sidebar-doc.htmlIn the sidebar section there are two menus
+ included the first is common to all the pages and contains
+ the download link and search box. Do not replace that
+ sidebar (/common/sidebar-common.html). It's the
+ second #include that should be changed to reflect
+ the current section.
+* Since this is a new page, you will also need to insert
+ your own corresponding copyright in the footer.
+* To insert the new content you need to insert it into the
+ section-body section. Replace the {stuff}
+ placeholder with the content you want. In addition you
+ might also want to change the title, in the head,
+ and in the section-title section.
+
+
+In addition to the immediate content for the new page one
+ needs to add an entry to the page so it can be accessed from
+ the sidebar and index. See below...
+
+
+Menus, Sidebars, and
+ Index
+---------------------------
+
+
+The various navigation elements are structured to make
+ adding new entries easy and to keep all places where wuch
+ entries show consistent. To do this the site makes use of SSI
+ to reduce the locations that have those entries to
+ *one*. This means that changing it at the single common
+ place one doesn't have to worry about changing all the pages,
+ they all reflect the new content immediately. To add items to
+ the various section menus edit the corresponding menu file in
+ the website/common directory:
+
+
+* Introduction: /common/menu-boost.html
+* Community: /common/menu-community.html
+* Development: /common/menu-development.html
+* Documentation: /generated/menu-doc.html
+
+
+Generated Pages
+---------------
+
+
+There are various sections of the web site that are
+ generated by a php script from quickbook source files: the home
+ page, news, downloads, version history and feeds. The content
+ is not directly editable, but instead is generated from source
+ Quickbook documents. For example, to add a news item one
+ would:
+
+
+1. Create a new file in the /feed/news directory,
+ say /feed/news/gui\_review\_ends.qbk.
+2. In a shell, run the /site-tools/update.py
+ script. This will generate the page for the new news item,
+ regenerate the /feed/news.rss file to include it,
+ update pages which link to the new item and update the file
+ /site-tools/state/feed-pages.txt which tracks the
+ current state of generated files.
+3. Add the new files to the SVN repository, and commit.
+
+
+The same procedure applies to the other feeds, but keep in
+ mind that some feeds may combine entries from more than one
+ feed subdirectory. Currently this requires Quickbook and Python
+ in your path.
+
+
+Local
+ Server
+-------------
+
+
+Even though the web site is designed so that one only needs
+ some basic tools and a web browser to make changes there are
+ some aspects that are dynamic and hence will not work without
+ an accompanying web server. To set up local web server for
+ doing changes to the dynamic content one needs to:
+
+
+1. Install and get working [Apache 2.x.](http://httpd.apache.org/) and [PHP 5.3 or later](http://php.net/) (install PHP as an
+ Apache module, not as CGI).
+2. Set up a symbolic host lookup in your hosts
+ file by adding "127.0.0.1 boost.localhost".
+3. Add a virtual host in Apache to match the new local
+ host. A likely configuration to work is:
+```
+
+<VirtualHost 127.0.0.1:80>
+  ServerName boost.localhost
+  DocumentRoot "/path/to/boost/website"
+  <Directory "/path/to/boost/website">
+    Options +MultiViews +Includes +ExecCGI +FollowSymLinks +Includes
+    AllowOverride All
+    Order allow,deny
+    Allow from all
+    # For apache 2.4:
+    # Require all granted
+  </Directory>
+</VirtualHost>
+
+```
+4. Create a local PHP configuration file for Boost specific
+ settings as
+ "/path/to/boost/website/common/code/boost\_config\_local.php"
+ that contains something like:
+```
+
+<?php
+define('BOOST\_WEBSITE\_SHARED\_DIR', '/path/to/boost/shared');
+define('STATIC\_DIR', '/path/to/boost/shared/archives/live');
+?>
+
+```
+
+For a brief explanation of the settings see the
+ [common/code/boost\_config.php](https://github.com/boostorg/website/blob/master/common/code/boost_config.php) file.
+5. In order to view the documentation, or the build
+ sub-site, you'll need to setup the appropriate directories.
+ /build needs to contain the [website
+ branch of Boost.Build](https://github.com/boostorg/build/tree/website). A soft link to another directory
+ can be used here (which is how it's done on the server).
+ STATIC\_DIR needs to be the location of unzipped
+ copies of the appropriate boost distribution to serve the
+ documentation. By default, boost\_config.php sets STATIC\_DIR
+ to $BOOST\_WEBSITE\_SHARED\_DIR/archives/live. Follow steps
+ similar to this, changing variables as necessary:
+```
+
+BOOST\_WEBSITE\_SHARED\_DIR=/home/www/shared
+mkdir -p $BOOST\_WEBSITE\_SHARED\_DIR/archives/live
+cd $BOOST\_WEBSITE\_SHARED\_DIR/archives/live
+wget https://boostorg.jfrog.io/artifactory/main/release/1.74.0/source/boost\_1\_74\_0.tar.gz
+tar -xvf boost\_1\_74\_0.tar.gz
+```
+
+
+### Ubuntu setup
+
+
+To setup the site on Ubuntu, I needed to do:
+```
+
+sudo apt-get install apache2 libapache2-mod-php5
+sudo a2enmod headers
+sudo a2enmod rewrite
+sudo a2enmod include
+sudo a2dismod deflate
+sudo service apache2 restart
+```
+
+I had to disable `deflate` because it interacts
+ badly with php's `virtual` function.
+
+
+
+
+
+
+
+
+

doc/_template_.html

@@ -0,0 +1,24 @@
+---
+title: Boost C++ Libraries
+copyright: Rene Rivera 2007.
+revised: 
+---
+
+
+Boost C++ Libraries
+
+
+
+Boost C++ Libraries
+===================
+
+{stuff}
+
+
+
+
+
+
+
+
+

doc/index.html

@@ -0,0 +1,57 @@
+---
+title: Boost C++ Libraries
+copyright: Beman Dawes, David Abrahams, 1998-2005. Rene Rivera 2004-2005.
+revised: 
+---
+
+
+Boost C++ Libraries
+
+
+/\*<![CDATA[\*/
+ #doc-index h4 {
+ display: none !important;
+ }
+ #doc-index span.link {
+ display: none !important;
+ }
+ /\*]]>\*/
+ 
+
+
+Documentation
+=============
+
+Much work goes into the documentation for the Boost
+ libraries and tools. The documentation included in the library
+ and tool release is also available here:
+
+
+Additional information about the testing and release practices,
+ infrastructure and in progress developments is available on
+ our [Trac wiki](https://svn.boost.org/trac/boost/).
+
+
+Translations
+------------
+
+
+Boost doesn't have the resources to translate the
+ documentation itself, but there is at least one separate group
+ translating the documentation. If you have formed another, tell
+ us on the [documentation list](/community/groups.html#boostdocs) and
+ we'll add a link.
+
+
+* [Chinese
+ translations](http://code.google.com/p/boost-doc-zh/) ([mailing
+ list](http://groups.google.com/group/boost_doc_translation))
+
+
+
+
+
+
+
+
+