Add dev pages

.gitignore

@@ -1,2 +1 @@
-html/**
-bin/**
+bin/**

Jamfile.v2

@@ -4,18 +4,9 @@
 
 import asciidoctor ;
 
-html boost-contributor-manual.html : doc/pages/index.adoc ;
+html index.html
+    : antora/modules/ROOT/pages/index.adoc
+      #[ glob antora/modules/ROOT/pages/*.adoc ]
+    ;
 
-install html_ : boost-contributor-manual.html : <location>html ;
-
-pdf boost-contributor-manual.pdf : doc/boost-contributor-manual.adoc ;
-explicit boost-contributor-manual.pdf ;
-
-install pdf_ : boost-contributor-manual.pdf : <location>pdf ;
-explicit pdf_ ;
-
-###############################################################################
-alias boostdoc ;
-explicit boostdoc ;
-alias boostrelease : html_ ;
-explicit boostrelease ;
+install html_ : index.html : <location>bin ;

antora/modules/ROOT/nav.adoc

@@ -1 +1,26 @@
-* Introduction
+* xref:intro.adoc[Introduction]
+* Development
+** xref:dev/borland_cpp.adoc[]
+** xref:dev/bugs.adoc[]
+** xref:dev/design_faq.adoc[]
+** xref:dev/exemplar.adoc[]
+** xref:dev/header.adoc[]
+** xref:dev/index.adoc[]
+** xref:dev/int_const_guidelines.adoc[]
+** xref:dev/library_metadata.adoc[]
+** xref:dev/report-apr-2006.adoc[]
+** xref:dev/report-dec-2009.adoc[]
+** xref:dev/report-jan-2006.adoc[]
+** xref:dev/report-jun-2009.adoc[]
+** xref:dev/report-may-2008.adoc[]
+** xref:dev/report-nov-2007.adoc[]
+** xref:dev/report-nov-2008.adoc[]
+** xref:dev/report-sep-2007.adoc[]
+** xref:dev/requirements.adoc[]
+** xref:dev/reuse.adoc[]
+** xref:dev/running_regression_tests.adoc[]
+** xref:dev/separate_compilation.adoc[]
+** xref:dev/submissions.adoc[]
+** xref:dev/test.adoc[]
+** xref:dev/testing.adoc[]
+** xref:dev/website_updating.adoc[]

antora/modules/ROOT/pages

@@ -1 +0,0 @@
-../../../doc/pages

antora/modules/ROOT/pages/dev/borland_cpp.adoc

@@ -0,0 +1,412 @@
+= Borland C++
+:idprefix:
+:idseparator: -
+:leveloffset: +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)
+
+Footer
+© 2023 GitHub, Inc.
+Footer navigation
+Terms
+Privacy
+Security
+Status
+Docs
+Contact GitHub
+Pricing
+API
+Training
+Blog
+About
+website2022/borland_cpp.html at master · boostorg/website2022

antora/modules/ROOT/pages/dev/bugs.adoc

@@ -0,0 +1,49 @@
+= Bugs
+:idprefix:
+:idseparator: -
+:leveloffset: +1
+
+
+
+
+
+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
+
+

antora/modules/ROOT/pages/dev/design_faq.adoc

@@ -0,0 +1,52 @@
+= Boost Website Design FAQ
+:idprefix:
+:idseparator: -
+:leveloffset: +1
+
+
+* 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.
+
+
+
+
+
+
+
+
+

antora/modules/ROOT/pages/dev/exemplar.adoc

@@ -0,0 +1,305 @@
+= Website Exemplars
+:idprefix:
+:idseparator: -
+:leveloffset: +1
+
+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):
+```
+```
+
+
+
+
+
+
+
+

antora/modules/ROOT/pages/dev/header.adoc

@@ -0,0 +1,97 @@
+= Boost Header policy
+:idprefix:
+:idseparator: -
+
+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.
+
+
+
+
+
+
+
+
+

antora/modules/ROOT/pages/dev/index.adoc

@@ -0,0 +1,66 @@
+= Boost Development
+:idprefix:
+:idseparator: -
+:leveloffset: +1
+
+/\*<![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.
+
+
+
+
+
+
+
+
+

antora/modules/ROOT/pages/dev/int_const_guidelines.adoc

@@ -0,0 +1,391 @@
+= Coding Guidelines for Integral Constant Expressions
+:idprefix:
+:idseparator: -
+
+== What is an Integral Constant Expression?
+
+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.
+
+
+
+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).
+
+
+
+
+
+
+
+
+

antora/modules/ROOT/pages/dev/library_metadata.adoc

@@ -0,0 +1,202 @@
+= Library Metadata
+:idprefix:
+:idseparator: -
+
+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
+
+
+
+
+
+
+
+

antora/modules/ROOT/pages/dev/report-apr-2006.adoc

@@ -0,0 +1,241 @@
+= Review Wizard Status Report for April 2006
+:idprefix:
+:idseparator: -
+
+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.
+
+
+
+
+
+
+
+
+

antora/modules/ROOT/pages/dev/report-dec-2009.adoc

@@ -0,0 +1,552 @@
+= Review Wizard Status Report for December 2009
+:idprefix:
+:idseparator: -
+
+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.
+

antora/modules/ROOT/pages/dev/report-jan-2006.adoc

@@ -0,0 +1,247 @@
+= Review Wizard Status Report for January 2006
+:idprefix:
+:idseparator: -
+
+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.
+
+
+
+
+
+
+

antora/modules/ROOT/pages/dev/report-jun-2009.adoc

@@ -0,0 +1,631 @@
+= Review Wizard Status Report for June 2009
+:idprefix:
+:idseparator: -
+
+== 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
+

antora/modules/ROOT/pages/dev/report-may-2008.adoc

@@ -0,0 +1,441 @@
+= Review Wizard Status Report for May 2008
+:idprefix:
+:idseparator: -
+
+== 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.
+
+
+
+

antora/modules/ROOT/pages/dev/report-nov-2007.adoc

@@ -0,0 +1,328 @@
+= Review Wizard Status Report for November 2007
+:idprefix:
+:idseparator: -
+
+== 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.
+
+
+
+
+
+
+
+
+

antora/modules/ROOT/pages/dev/report-nov-2008.adoc

@@ -0,0 +1,548 @@
+= Review Wizard Status Report for November 2008
+:idprefix:
+:idseparator: -
+
+== 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. |
+

antora/modules/ROOT/pages/dev/report-sep-2007.adoc

@@ -0,0 +1,244 @@
+= Review Wizard Status Report for September 2007
+:idprefix:
+:idseparator: -
+
+== 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.
+
+
+
+
+
+
+
+
+

antora/modules/ROOT/pages/dev/requirements.adoc

@@ -0,0 +1,904 @@
+= Boost Library Requirements and Guidelines
+:idprefix:
+:idseparator: -
+
+
+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.
+
+
+
+
+
+
+

antora/modules/ROOT/pages/dev/reuse.adoc

@@ -0,0 +1,77 @@
+= Boost Library Reuse
+:idprefix:
+:idseparator: -
+
+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.
+
+
+
+
+
+
+
+
+

antora/modules/ROOT/pages/dev/running_regression_tests.adoc

@@ -0,0 +1,288 @@
+= Running Boost Regression Tests
+:idprefix:
+:idseparator: -
+
+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.
+> 
+> 
+> 
+3. 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.
+
+
+
+
+
+
+
+
+

antora/modules/ROOT/pages/dev/separate_compilation.adoc

@@ -0,0 +1,523 @@
+= Guidelines for Authors of Boost Libraries Containing Separate Source
+:idprefix:
+:idseparator: -
+
+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.
+
+
+
+
+
+
+
+
+

antora/modules/ROOT/pages/dev/submissions.adoc

@@ -0,0 +1,330 @@
+= Boost Library Submission Process
+:idprefix:
+:idseparator: -
+
+
+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)
+
+
+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.
+
+
+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.
+
+
+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.
+
+
+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.
+
+
+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
+
+
+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.
+
+
+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.
+
+
+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.
+
+
+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.
+
+
+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).
+
+
+
+
+
+
+
+
+

antora/modules/ROOT/pages/dev/test.adoc

@@ -0,0 +1,116 @@
+= Boost Test Policies and Protocols
+:idprefix:
+:idseparator: -
+
+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.
+
+---
+
+
+
+
+
+
+
+
+

antora/modules/ROOT/pages/dev/testing.adoc

@@ -0,0 +1,135 @@
+= Testing
+:idprefix:
+:idseparator: -
+
+
+
+/\*<![CDATA[\*/
+ th.c1 {font-style: italic}
+ /\*]]>\*/
+ 
+
+
+* [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).
+
+
+
+
+
+
+
+
+

antora/modules/ROOT/pages/dev/website_updating.adoc

@@ -0,0 +1,312 @@
+= Boost C++ Libraries - Updating Website
+:idprefix:
+:idseparator: -
+
+
+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.
+
+
+
+
+
+
+
+
+

antora/modules/ROOT/pages/index.adoc

@@ -7,7 +7,4 @@
 :source-language: c++
 :nofooter:
 :sectlinks:
-
-:leveloffset: +1
-
-include::intro.adoc[]
+:doctype: article

antora/modules/ROOT/pages/intro.adoc

@@ -1,7 +1,7 @@
-[#intro]
 = Introduction
-
-:idprefix: intro_
+:idprefix:
+:idseparator: -
+:leveloffset: +1
 
 Boost is a collection of peer-reviewed and high-quality libraries that aim to
 make application development simple and straight-forward for everyone!