mirror of
https://github.com/boostorg/more.git
synced 2024-12-25 23:20:12 +08:00
Full merge from trunk at revision 41356 of entire boost-root tree.
[SVN r41372]
This commit is contained in:
parent
ff55617952
commit
5af731ce03
BIN
BoostSponsorshipAgreement.pdf
Normal file
BIN
BoostSponsorshipAgreement.pdf
Normal file
Binary file not shown.
@ -4,7 +4,7 @@
|
||||
import docutils ;
|
||||
|
||||
import path ;
|
||||
sources = getting_started.rst ;
|
||||
sources = getting_started.rst BoostCon07.rst ;
|
||||
bases = $(sources:S=) ;
|
||||
|
||||
# This is a path relative to the html/ subdirectory where the
|
||||
|
221
background.html
221
background.html
@ -1,221 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Language" content="en-us">
|
||||
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
||||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
||||
<title>
|
||||
Boost Background Information
|
||||
</title>
|
||||
<style type="text/css">
|
||||
body {
|
||||
background-color: #FFFFFF;
|
||||
}
|
||||
p.c2 {font-style: italic; font-weight: bold}
|
||||
span.c1 {color: #FFFFFF; font-family: Arial; font-size: 120%}
|
||||
</style>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<table summary="Navigational header"
|
||||
border="1" cellpadding="2" bgcolor="#007F7F">
|
||||
<tr>
|
||||
<td bgcolor="#FFFFFF">
|
||||
<img src="../boost.png" alt="boost.png (6897 bytes)" width="277"
|
||||
height="86">
|
||||
</td>
|
||||
<td>
|
||||
<a href="../index.htm"><span class="c1">Home</span></a>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
<a href="../libs/libraries.htm"><span class="c1">Libraries</span></a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="../people/people.htm"><span class="c1">People</span></a>
|
||||
</td>
|
||||
<td>
|
||||
|
||||
<a href="../more/faq.htm"><span class="c1">FAQ</span></a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="../more/index.htm"><span class="c1">More</span></a>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<h1>
|
||||
|
||||
Boost Background Information
|
||||
</h1>
|
||||
<h2>
|
||||
Why should an organization use Boost?
|
||||
</h2>
|
||||
<p>
|
||||
In a word, <i><b>Productivity</b></i>. Use of high-quality libraries like
|
||||
Boost speeds initial development, results in fewer bugs, reduces
|
||||
reinvention-of-the-wheel, and cuts long-term maintenance costs. And since
|
||||
Boost libraries tend to become de facto or de jure standards, many
|
||||
programmers are already familiar with them.
|
||||
</p>
|
||||
<p>
|
||||
|
||||
Ten of the Boost libraries are included in the <a href=
|
||||
"http://open-std.org/jtc1/sc22/wg21/docs/library_technical_report.html">C++
|
||||
Standard Library's TR1</a>, and so are slated for later full
|
||||
standardization. More Boost libraries are in the pipeline for <a href=
|
||||
"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html">TR2</a>.
|
||||
Using Boost libraries gives an organization a head-start in adopting new
|
||||
technologies.
|
||||
</p>
|
||||
<p>
|
||||
Many organization already use programs implemented with Boost, like Adobe
|
||||
<a href="http://www.adobe.com/products/acrobat/readermain.html">Acrobat
|
||||
Reader 7.0</a>.
|
||||
</p>
|
||||
<h2>
|
||||
Who else is using Boost?
|
||||
</h2>
|
||||
|
||||
<p>
|
||||
See the <a href="../doc/html/who_s_using_boost_.html">Who's Using Boost
|
||||
page</a> for a sampling. We don't know the exact numbers, but a release
|
||||
gets around 100,000 downloads from SourceForge, and that is only one of
|
||||
several distribution routes.
|
||||
</p>
|
||||
<h2>
|
||||
What do others say about Boost?
|
||||
</h2>
|
||||
<p class="c2">
|
||||
"...one of the most highly regarded and expertly designed C++ library
|
||||
projects in the world."
|
||||
</p>
|
||||
|
||||
<blockquote>
|
||||
<p>
|
||||
-- <a href="http://www.gotw.ca/">Herb Sutter</a> and <a href=
|
||||
"http://en.wikipedia.org/wiki/Andrei_Alexandrescu">Andrei
|
||||
Alexandrescu</a>, <a href=
|
||||
"http://safari.awprofessional.com/?XmlId=0321113586">C++ Coding
|
||||
Standards</a>
|
||||
</p>
|
||||
</blockquote>
|
||||
|
||||
<p class="c2">
|
||||
"Item 55: Familiarize yourself with Boost."
|
||||
</p>
|
||||
<blockquote>
|
||||
<p>
|
||||
-- <a href="http://www.aristeia.com/">Scott Meyers</a>, <a href=
|
||||
"http://www.awl.com/cseng/titles/0-321-33487-6/">Effective C++, 3rd
|
||||
Ed.</a>
|
||||
</p>
|
||||
|
||||
</blockquote>
|
||||
<p class="c2">
|
||||
"The obvious solution for most programmers is to use a library that
|
||||
provides an elegant and efficient platform independent to needed services.
|
||||
Examples are BOOST..."
|
||||
</p>
|
||||
<blockquote>
|
||||
<p>
|
||||
-- <a href="http://www.research.att.com/~bs/">Bjarne Stroustrup</a>,
|
||||
<a href="http://www.research.att.com/~bs/abstraction.pdf">Abstraction,
|
||||
libraries, and efficiency in C++</a>
|
||||
|
||||
</p>
|
||||
</blockquote>
|
||||
<h2>
|
||||
How do users get support?
|
||||
</h2>
|
||||
<p>
|
||||
For relatively straightforward support needs, users rely on the <a href=
|
||||
"mailing_lists.htm">mailing lists</a>. One of the advantages of Boost is
|
||||
the responsiveness of other users and Boost developers.
|
||||
</p>
|
||||
<p>
|
||||
|
||||
For more involved needs, <a href="links.htm#CommercialSupport">Commercial
|
||||
Support</a> is available.
|
||||
</p>
|
||||
<h2>
|
||||
What about license issues?
|
||||
</h2>
|
||||
<p>
|
||||
Boost has its own <a href="license_info.html">license</a>, developed with
|
||||
help from the Harvard Law School. The <a href=
|
||||
"license_info.html">Boost license polices</a> encourage both commercial and
|
||||
non-commercial use, and the Boost license is not related to the GPL or
|
||||
other licenses - that are sometimes seen as business unfriendly.
|
||||
</p>
|
||||
|
||||
<h2>
|
||||
What about other intellectual property issues?
|
||||
</h2>
|
||||
<p>
|
||||
The Boost libraries tend to be new, fresh, and creative designs. They are
|
||||
not copies, clones, or derivations of proprietary libraries. Boost has a
|
||||
firm policy to respect the IP rights of others. The development of Boost
|
||||
libraries is publicly documented via the mailing lists and version control
|
||||
repository. The source code has been inspected by many, many knowledgeable
|
||||
programmers. Each Boost file has a copyright notice and license
|
||||
information. IP issues have been reviewed by the legal teams from some of
|
||||
the corporations which use Boost, and in some cases these lawyers have been
|
||||
kind enough to give Boost feedback on IP issues. There are no guarantees,
|
||||
but those factors all tend to reduce IP risk.
|
||||
</p>
|
||||
<h2>
|
||||
Why would anyone give away valuable software for free?
|
||||
</h2>
|
||||
<p>
|
||||
|
||||
Businesses and other organizations often prefer to have code developed,
|
||||
maintained, and improved in the open source community when it does not
|
||||
contain technology specific to their application domain, because it allows
|
||||
them to focus more development resources on their core business.
|
||||
</p>
|
||||
<p>
|
||||
Individuals contribute for the technical challenge, to hone their technical
|
||||
skills, for the sense of community, as part of their graduate school
|
||||
programs, as a way around geographic isolation, to enhance their employment
|
||||
opportunities, and as advertisements for their consulting services. There
|
||||
are probably as many reasons as there are individuals. Some of the
|
||||
apparently individual contributions come from employees of support
|
||||
companies with contracts from businesses or other organizations who have an
|
||||
interest in seeing that a library is well-maintained.
|
||||
</p>
|
||||
<h2>
|
||||
Who pays Boost's expenses?
|
||||
</h2>
|
||||
<p>
|
||||
Boost doesn't really have any expenses! All the infrastructure is
|
||||
contributed by supporters, such as the <a href=
|
||||
"http://www.osl.iu.edu/">Open Systems Lab</a> at Indiana University,
|
||||
|
||||
<a href="http://sourceforge.net/index.php">SourceForge</a>, <a href=
|
||||
"http://www.boost-consulting.com/">Boost Consulting</a>, <a href=
|
||||
"http://www.meta-comm.com/">MetaCommunications</a>, and the individuals,
|
||||
companies, and other organizations who run the regression tests. Borland,
|
||||
HP, Intel, and Microsoft have contributed compilers. And hundreds, or even
|
||||
thousands, of programmers contribute their time. That's what makes Boost
|
||||
possible.
|
||||
</p>
|
||||
<hr>
|
||||
<p>
|
||||
Revised <!--webbot bot="Timestamp" s-type="EDITED"
|
||||
s-format="%d %B, %Y" startspan -->07 July, 2005
|
||||
<!--webbot bot="Timestamp" endspan i-checksum="21138" -->
|
||||
</p>
|
||||
|
||||
<p>
|
||||
© Copyright Beman Dawes 2005.
|
||||
</p>
|
||||
<p>
|
||||
Distributed under the Boost Software License, Version 1.0. (See
|
||||
accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy
|
||||
at <a href=
|
||||
"http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>)
|
||||
</p>
|
||||
</body>
|
||||
|
||||
</html>
|
@ -1,538 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<title>Boost Bibliography</title>
|
||||
</head>
|
||||
<body bgColor="#ffffff">
|
||||
<table summary="Navigational header" cellPadding="2" bgColor="#007f7f" border="1">
|
||||
<tr>
|
||||
<td bgColor="#ffffff"><IMG height="86" alt="boost.png (6897 bytes)" src="../boost.png" width="277"></td>
|
||||
<td><A href="../index.htm"><font face="Arial" color="#ffffff" size="4">Home</font></A></td>
|
||||
<td><A href="../libs/libraries.htm"><font face="Arial" color="#ffffff" size="4">Libraries</font></A></td>
|
||||
<td><A href="../people/people.htm"><font face="Arial" color="#ffffff" size="4">People</font></A></td>
|
||||
<td><A href="faq.htm"><font face="Arial" color="#ffffff" size="4">FAQ</font></A></td>
|
||||
<td><A href="index.htm"><font face="Arial" color="#ffffff" size="4">More</font></A></td>
|
||||
</tr>
|
||||
</table>
|
||||
<h1>Boost Bibliography</h1>
|
||||
<p><A href="#Print_publications">Print publications about Boost or Boost Libraries</A><br>
|
||||
<A href="#Online_publications">Online publications about Boost or Boost Libraries</A><br>
|
||||
<A href="#Print_mentions">Print mentions of Boost or Boost Libraries</A><br>
|
||||
<A href="#Online_mentions">Online mentions of Boost or Boost Libraries</A><br>
|
||||
<A href="#update">How to update this page</A><br>
|
||||
<a href="#Acknowledgements">Acknowledgements</a></p>
|
||||
<h2><a name="Print_publications">Print publications</a> about Boost or Boost
|
||||
Libraries</h2>
|
||||
<table summary="List of print publications about Boost or its libraries"
|
||||
style="BORDER-COLLAPSE: collapse" cellPadding="5" width="100%"
|
||||
border="0">
|
||||
<tr>
|
||||
<td vAlign="top" align="left" width="16%"><b>[<a name="MaddockCleary00">MaddockCleary00</a>]</b></td>
|
||||
<td vAlign="top" align="left" width="84%">John Maddock and Steve Cleary, <i>C++ Type
|
||||
Traits</i>. Dr. Dobb's Journal, Vol. 25, Issue 10, October, 2000, page 38. <a href="http://www.boost.org/libs/type_traits/cxx_type_traits.htm">
|
||||
www.boost.org/libs/type_traits/c++_type_traits.htm</a></td>
|
||||
</tr>
|
||||
|
||||
<!-- year separator -->
|
||||
<tr><td> </td><td> </td></tr>
|
||||
|
||||
<tr>
|
||||
<td vAlign="top" align="left" width="16%"><b>[<a name="Maddock01">Maddock01</a>]</b></td>
|
||||
<td vAlign="top" align="left" width="84%">John Maddock, <i>Regular Expressions in C++</i>.
|
||||
Dr. Dobb's Journal, Vol. 26, Issue 10, October, 2001, page 21.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td vAlign="top" align="left" width="16%"><b>[<a name="SiekLumsdaine01">SiekLumsdaine01</a>]</b></td>
|
||||
<td vAlign="top" align="left" width="84%">Jeremy Siek and Andrew Lumsdaine, <i>C++
|
||||
Concept Checking</i>. Dr. Dobb's Journal, Vol. 26, Issue 6, June, 2001,
|
||||
page 64.</td>
|
||||
</tr>
|
||||
|
||||
<!-- year separator -->
|
||||
<tr><td> </td><td> </td></tr>
|
||||
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Karlsson02">Karlsson02</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Björn Karlsson, <i>Smart Pointers in Boost</i>.
|
||||
C/C++ Users Journal, April, 2002. <A href="http://www.cuj.com/documents/s=8014/cuj0204karlsson/">
|
||||
www.cuj.com/documents/s=8014/cuj0204karlsson/</A>
|
||||
</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Karlsson02a">Karlsson02a</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Björn Karlsson, <i>C/C++ Tip #9: Lexical
|
||||
Conversions</i>. C/C++ Users Journal, November, 2002. <A href="http://www.cuj.com/documents/s=8470/cuj0211karlsson/">
|
||||
www.cuj.com/documents/s=8470/cuj0211karlsson/</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Kempf02">Kempf02</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Bill Kempf, <i>The Boost.Threads Library</i>.
|
||||
C/C++ Users Journal, May, 2002. <A href="http://www.cuj.com/documents/s=8013/cuj0205kempf/">
|
||||
www.cuj.com/documents/s=8013/cuj0205kempf/</A></TD>
|
||||
</TR>
|
||||
<tr>
|
||||
<td vAlign="top" align="left" width="16%"><b>[<a name="SiekLeeLumsdaine02">SiekLeeLumsdaine02</a>]</b></td>
|
||||
<td vAlign="top" align="left" width="84%">
|
||||
Jeremy Siek, Lie-Quan Lee and Andrew Lumsdaine, <i>The Boost Graph Library</i>.
|
||||
Addison-Wesley, 2002. ISBN: 0-201-72914-8. <a href="http://www.awprofessional.com/titles/0-201-72914-8">
|
||||
www.awprofessional.com/titles/0-201-72914-8/</a>
|
||||
<br>A sample chapter is available at: <A href="http://tinyurl.com/24666">tinyurl.com/24666</A>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<!-- year separator -->
|
||||
<tr><td> </td><td> </td></tr>
|
||||
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="AbrahamsGrosse-Kunstleve03">AbrahamsGrosse-Kunstleve03</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">David Abrahams and Ralf W.
|
||||
Grosse-Kunstleve, <i>Building Hybrid Systems with Boost.Python</i>. C/C++ Users
|
||||
Journal, July, 2003. <A href="http://www.cuj.com/documents/s=8470/cuj0307abrahams/">
|
||||
www.cuj.com/documents/s=8470/cuj0307abrahams/</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="GuzmanNuffer03">GuzmanNuffer03</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Joel de Guzman and Dan Nuffer, <i>The Spirit
|
||||
Library: Inline Parsing in C++</i>. C/C++ Users Journal, September, 2003,
|
||||
Vol. 21, Issue 9, page 22.</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Karlsson03">Karlsson03</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Björn Karlsson, <i>Lambda Expressions &
|
||||
C++</i>. C/C++ Users Journal, December, 2003, Vol. 21, Issue 12, page 20.</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Sutter03">Sutter03</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Herb Sutter, <i>Generalized Function Pointers</i>.
|
||||
C/C++ Users Journal, August, 2003. <A href="http://www.cuj.com/documents/s=8464/cujcexp0308sutter/">
|
||||
www.cuj.com/documents/s=8464/cujcexp0308sutter/</A>
|
||||
</TD>
|
||||
</TR>
|
||||
|
||||
<!-- year separator -->
|
||||
<tr><td> </td><td> </td></tr>
|
||||
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="AbrahamsGurtovoy04">AbrahamsGurtovoy04</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">
|
||||
David Abrahams and Aleksey Gurtovoy, <i>C++ Template Metaprogramming: Concepts,
|
||||
Tools, and Techniques from Boost and Beyond</i>. Addison-Wesley, November,
|
||||
2004. ISBN: 0-321-22725-5. <A href="http://www.awprofessional.com/titles/0321227255/">
|
||||
www.awprofessional.com/titles/0321227255/</A>
|
||||
<br>
|
||||
Additional information and two sample chapters are available at: <A href="http://boost-consulting.com/tmpbook/">
|
||||
boost-consulting.com/tmpbook/</A>
|
||||
</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Inaba04">Inaba04</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">
|
||||
Kazuhiro Inaba, <i>Boost C++ Library Programming</i>. Shuwa System, May, 2004. ISBN: 4-7980-0786-2. <A href="http://www.shuwasystem.co.jp/books/7980/0786-2/0786-2.html">
|
||||
www.shuwasystem.co.jp/books/7980/0786-2/0786-2.html</A>
|
||||
<br>
|
||||
Additional information and a sample chapter are available at: <A href="http://www.kmonos.net/pub/BoostBook/">
|
||||
www.kmonos.net/pub/BoostBook/</A>
|
||||
</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Lopez04">López04</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Joaquín M López Muñoz,
|
||||
<i>The Boost Multi-Index Containers Library</i>. C/C++ Users Journal,
|
||||
September, 2004, Vol. 22, Issue 9, page 6.</TD>
|
||||
</TR>
|
||||
|
||||
<!-- year separator -->
|
||||
<tr><td> </td><td> </td></tr>
|
||||
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Karlsson05">Karlsson05</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">
|
||||
Björn Karlsson, <i>Beyond the C++ Standard Library: An Introduction to Boost</i>. Addison-Wesley, August 31, 2005. ISBN: 0-3211-3354-4. <A href="http://www.awprofessional.com/titles/0321133544/">
|
||||
www.awprofessional.com/titles/0321133544/</A>
|
||||
<br>
|
||||
A sample chapter is available at: <A href="http://www.awprofessional.com/content/images/0321133544/samplechapter/karlsson_ch09.pdf">
|
||||
www.awprofessional.com/content/images/0321133544/samplechapter/karlsson_ch09.pdf</A>
|
||||
</TD>
|
||||
</TR>
|
||||
|
||||
</table>
|
||||
<h2><a name="Online_publications">Online publications</a> about Boost or Boost
|
||||
Libraries</h2>
|
||||
<table summary = "Online publications"
|
||||
style="BORDER-COLLAPSE: collapse" cellPadding="5" width="100%"
|
||||
border="0">
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Brownell02">Brownell02</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">David Brownell, <i>C++ Techniques for
|
||||
Tomorrow That Can be Implemented Today (a.k.a. Boosting your Code)</i>.
|
||||
NWCPP, November 13, 2002. <A href="http://www.nwcpp.org/Meetings/2002/11.html">www.nwcpp.org/Meetings/2002/11.html</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Long02">Long02</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Matt Long, <i>Adding Regular Expressions to Your App with Regex++</i>.
|
||||
The Code Project, June 18, 2002. <A href="http://www.codeproject.com/string/regex__.asp">www.codeproject.com/string/regex__.asp</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Siek02">Siek02</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Jeremy G. Siek, <i>The Boost Graph Library</i>.
|
||||
InformIT, March 1, 2002. <A href="http://tinyurl.com/2hc27">tinyurl.com/2hc27</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Siek02a">Siek02a</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Jeremy G. Siek, <i>A Boost Graph Library
|
||||
Tutorial</i>. InformIT, March 1, 2002. <A href="http://tinyurl.com/2sa4s">tinyurl.com/2sa4s</A></TD>
|
||||
</TR>
|
||||
|
||||
<!-- year separator -->
|
||||
<tr><td> </td><td> </td></tr>
|
||||
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%" height="32"><b>[<a name="Abrahams03">Abrahams03</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%" height="30">David Abrahams, <i>The Boost
|
||||
Metaprogramming Library</i>. ACCU, 2003. <A href="http://www.boost-consulting.com/writing/ACCU_MPL_slides.ppt">
|
||||
www.boost-consulting.com/writing/ACCU_MPL_slides.ppt</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Dawes03">Dawes03</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Beman Dawes, <i>Multiplatform Software
|
||||
Development</i>. 2003. <A href="http://www.esva.net/~beman/multiplat_dev.ppt">www.esva.net/~beman/multiplat_dev.ppt</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left"><b>[<a name="Halleux03">Halleux03</a>]</b></TD>
|
||||
<TD vAlign="top" align="left">Jonathan de Halleux, <i>Opening a door
|
||||
towards Spirit: a parser framework</i>. The Code Project, March 24, 2003. <A href="http://www.codeproject.com/cpp/spiritintro.asp"> www.codeproject.com/cpp/spiritintro.asp</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left"><b>[<a name="Kaiser03">Kaiser03</a>]</b></TD>
|
||||
<TD vAlign="top" align="left">Hartmut Kaiser, <i>Wave: a Standard conformant C++ preprocessor library</i>. The Code Project, March 25, 2003. <A href="http://www.codeproject.com/cpp/wave_preprocessor.asp"> www.codeproject.com/cpp/wave_preprocessor.asp</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Trentini03">Trentini03</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Matthew S. Trentini, <i>Introduction to Boost</i>.</TD>
|
||||
</TR>
|
||||
<tr>
|
||||
<td vAlign="top" align="left" width="16%"><b>[<a name="Walker03">Walker03</a>]</b> </td>
|
||||
<td vAlign="top" align="left" width="84%">Andrew Walker, <i>An Introduction to Boost</i>.
|
||||
The Code Project, July 7, 2003. <a href="http://www.codeproject.com/vcpp/stl/BoostIntro.asp">
|
||||
www.codeproject.com/vcpp/stl/BoostIntro.asp</a>
|
||||
<br>A short and straightforward introduction to Boost. </td>
|
||||
</tr>
|
||||
|
||||
<!-- year separator -->
|
||||
<tr><td> </td><td> </td></tr>
|
||||
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Dawes04">Dawes04</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Beman Dawes, <i>Boost for Visual C++
|
||||
Developers</i>. MSDN, May 17, 2004. <A href="http://tinyurl.com/2lzyh">tinyurl.com/2lzyh</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="DAgostino04">D'Agostino04</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Jim D'Agostino, <i>Designing Robust Objects with Boost</i>.
|
||||
The Code Project, August 17, 2004. <A href="http://www.codeproject.com/cpp/Designing_Robust_Objects.asp">
|
||||
www.codeproject.com/cpp/Designing_Robust_Objects.asp</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Handley04">Handley04</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Dave Handley, <i>An Introduction to the Boost Spirit Parser framework</i>.
|
||||
The Code Project, October 9, 2004. <A href="http://www.codeproject.com/vcpp/stl/introduction_spirit.asp">
|
||||
www.codeproject.com/vcpp/stl/introduction_spirit.asp</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Handley04a">Handley04a</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Dave Handley, <i>Implementing Semantic Actions in the Boost Spirit Parser Framework</i>.
|
||||
The Code Project, October 10, 2004. <A href="http://www.codeproject.com/vcpp/stl/spirit_semantic_actions.asp">
|
||||
www.codeproject.com/vcpp/stl/spirit_semantic_actions.asp</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Hauptmann04">Hauptmann04</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Peter Hauptmann, <i>Smart Pointers to boost your
|
||||
code</i>. The Code Project, September 27, 2004. <A href="http://www.codeproject.com/vcpp/stl/boostsmartptr.asp">
|
||||
www.codeproject.com/vcpp/stl/boostsmartptr.asp</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Hauptmann04a">Hauptmann04a</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Peter Hauptmann, <i>boost 2: shared_ptr wraps
|
||||
resource handles</i>. The Code Project, October 4, 2004. <A href="http://www.codeproject.com/vcpp/stl/boostsp_handleref.asp">
|
||||
www.codeproject.com/vcpp/stl/boostsp_handleref.asp</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Wikipedia04">Wikipedia04</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Wikipedia, <i>Boost</i>.
|
||||
Wikipedia, The Free Encyclopedia, 2004. <A href="http://en.wikipedia.org/wiki/Boost%20library">
|
||||
en.wikipedia.org/wiki/Boost_(programming)</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Witt04">Witt04</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Thomas Witt, <i>The Boost Iterator Library</i>.
|
||||
ACCU Spring Conference, 2004. <A href="http://www.accu.org/conference/presentations/Witt_-_Boost_Iterator_Library.pdf">
|
||||
www.accu.org/conference/presentations/Witt_-_Boost_Iterator_Library.pdf</A></TD>
|
||||
</TR>
|
||||
|
||||
<!-- year separator -->
|
||||
<tr><td> </td><td> </td></tr>
|
||||
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Karlsson05a">Karlsson05a</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Bjorn Karlsson, <i>How the Boost Bind Library Can Improve Your C++ Programs</i>. InformIT, August 26, 2005. <A href="http://www.informit.com/articles/article.asp?p=412354">
|
||||
http://www.informit.com/articles/article.asp?p=412354</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Cogswell05">Cogswell05</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Jeff Cogswell, <i>Adding an Easy File Save and File Load Mechanism
|
||||
to Your C++ Program</i>. InformIT, July 1, 2005. <A href="http://www.informit.com/articles/article.asp?p=398702">
|
||||
http://www.informit.com/articles/article.asp?p=398702</A>
|
||||
<br>Explains Boost.Serialization.</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Gurtovoy05">Gurtovoy05</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Aleksey Gurtovoy and David Abrahams <i>An In-Depth Look at Metafunctions in C++</i>. InformIT, April 1, 2005. <A href="http://www.informit.com/articles/article.asp?p=375705">
|
||||
http://www.informit.com/articles/article.asp?p=375705</A></TD>
|
||||
</TR>
|
||||
</table>
|
||||
<h2><a name="Print_mentions">Print mentions</a> of Boost or Boost Libraries</h2>
|
||||
<table summary="Print mentions"
|
||||
style="BORDER-COLLAPSE: collapse" cellPadding="5" width="100%"
|
||||
border="0">
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="HyslopSutter01">HyslopSutter01</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Jim Hyslop and Herb Sutter, <i>Conversations:
|
||||
I'd Hold Anything for You</i>. C/C++ Users Journal, December, 2001. <A href="http://www.cuj.com/documents/s=7988/cujcexp1912hyslop/">
|
||||
www.cuj.com/documents/s=7988/cujcexp1912hyslop/</A>
|
||||
<br><CODE>boost::any</CODE>
|
||||
</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Meyers01">Meyers01</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Scott Meyers, <i>Item 50: Familiarize yourself with
|
||||
STL-related web sites</i>. Effective STL, Addison-Wesley, 2001, page 221. ISBN: 0-201-74962-9
|
||||
</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Sutter01">Sutter01</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Herb Sutter, <i>The String Formatters of
|
||||
Manor Farm</i>. C/C++ Users Journal, Vol. 19, November, 2001. <A href="http://www.gotw.ca/publications/mill19.htm">
|
||||
www.gotw.ca/publications/mill19.htm</A>
|
||||
<br><CODE>boost::lexical_cast</CODE>
|
||||
</TD>
|
||||
</TR>
|
||||
|
||||
<!-- year separator -->
|
||||
<tr><td> </td><td> </td></tr>
|
||||
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Ablavsky02">Ablavsky02</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Vitaly Ablavsky, <i>Applying BGL to
|
||||
Computational Geometry</i>. C/C++ Users Journal, August, 2002. <A href="http://www.cuj.com/documents/s=8470/cuj0208ablavsky/">
|
||||
www.cuj.com/documents/s=8470/cuj0208ablavsky/</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Alexandrescu02">Alexandrescu02</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Andrei Alexandrescu, <i>Generic<Programming>:
|
||||
Efficient Generic Sorting and Searching in C++ (I): In Search of a Better
|
||||
Search</i>. C/C++ Users Journal, October, 2002. <A href="http://www.cuj.com/documents/s=7978/cujcexp2010alexandr/">
|
||||
www.cuj.com/documents/s=7978/cujcexp2010alexandr/</A>
|
||||
<br><CODE>boost::type_traits</CODE>
|
||||
</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="HyslopSutter02">HyslopSutter02</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Jim Hyslop and Herb Sutter, <i>Conversations:
|
||||
Getting to the Point</i>. C/C++ Users Journal, July, 2002. <A href="http://www.cuj.com/documents/s=7981/cujcexp2007hyslop/">
|
||||
www.cuj.com/documents/s=7981/cujcexp2007hyslop/</A>
|
||||
<br>smart pointer discussion. <CODE>boost::scoped_ptr, shared_ptr, scoped_array,
|
||||
shared_array.</CODE>
|
||||
</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Sutter02">Sutter02</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Herb Sutter, <i>The New C++: The Group of
|
||||
Seven - Extensions under Consideration for the C++ Standard Library</i>.
|
||||
C/C++ Users Journal, April, 2002. <A href="http://www.cuj.com/documents/s=7984/cujcexp2004sutter/">
|
||||
www.cuj.com/documents/s=7984/cujcexp2004sutter/</A>
|
||||
</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Sutter02a">Sutter02a</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Herb Sutter, <i>The New C++: Smart(er)
|
||||
Pointers</i>. C/C++ Users Journal, August, 2002. <A href="http://www.cuj.com/documents/s=7980/cujcexp2008sutter/">
|
||||
www.cuj.com/documents/s=7980/cujcexp2008sutter/</A></TD>
|
||||
</TR>
|
||||
|
||||
<!-- year separator -->
|
||||
<tr><td> </td><td> </td></tr>
|
||||
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Besser03">Besser03</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Mitch Besser, <i>Generic Printable ENUM++</i>.
|
||||
C/C++ Users Journal, June, 2003. <A href="http://www.cuj.com/documents/s=8470/cujboost0306besser/">
|
||||
www.cuj.com/documents/s=8470/cujboost0306besser/</A>
|
||||
<br>Mentions <CODE>BOOST_PP</CODE>
|
||||
</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Nasonov03">Nasonov03</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Alexander Nasonov, <i>I/O System: dynamic_any
|
||||
Campaign</i>. C/C++ Users Journal, September, 2003. <A href="http://www.cuj.com/documents/s=8470/cujweb0309nasonov/">
|
||||
www.cuj.com/documents/s=8470/cujweb0309nasonov/</A>
|
||||
<br>Improved <CODE>boost::any</CODE>
|
||||
</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Sutter03a">Sutter03a</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Herb Sutter, <i>Generalizing Observer</i>.
|
||||
C/C++ Users Journal, September, 2003. <A href="http://www.cuj.com/documents/s=8840/cujexp0309sutter/">
|
||||
www.cuj.com/documents/s=8840/cujexp0309sutter/</A>
|
||||
</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Tan03">Tan03</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Kwee H. Tan, <i>Exploring EDA Algorithms with
|
||||
the Boost Graph Library</i>. C/C++ Users Journal, July, 2003. <A href="http://www.cuj.com/documents/s=8470/cuj0307tan/">
|
||||
www.cuj.com/documents/s=8470/cuj0307tan/</A>
|
||||
</TD>
|
||||
</TR>
|
||||
<tr>
|
||||
<td vAlign="top" align="left" width="16%"><b>[<a name="VandervoordeJosuttis03">VandervoordeJosuttis03</a>]</b>
|
||||
</td>
|
||||
<td vAlign="top" align="left" width="84%">David Vandevoorde and Nicolai M.
|
||||
Josuttis, <i>Using Templates in Practice</i>. C/C++ Users Journal, February,
|
||||
2003. <A href="http://www.cuj.com/documents/s=8208/cujweb0302vandevoorde/web0302b.htm">
|
||||
www.cuj.com/documents/s=8208/cujweb0302vandevoorde/web0302b.htm</A>
|
||||
<br>Concept Check Library
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<!-- year separator -->
|
||||
<tr><td> </td><td> </td></tr>
|
||||
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Meyers05">Meyers05</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Scott Meyers, <i>Item 55: Familiarize yourself
|
||||
with Boost</i>. Effective C++, 3rd Edition, Addison-Wesley, May 12, 2005. ISBN: 0-321-33487-6
|
||||
</TD>
|
||||
</TR>
|
||||
</table>
|
||||
<h2><a name="Online_mentions">Online mentions</a> of Boost or Boost Libraries</h2>
|
||||
<table summary="Online mentions"
|
||||
style="BORDER-COLLAPSE: collapse" cellPadding="5" width="100%"
|
||||
border="0">
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Siek01">Siek01</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Jeremy G. Siek, <i>An Implementation of Graph Isomorphism Testing</i>,
|
||||
December 9, 2001. <A href="http://www.boost.org/libs/graph/doc/isomorphism-impl.pdf">
|
||||
www.boost.org/libs/graph/doc/isomorphism-impl.pdf</A></TD>
|
||||
</TR>
|
||||
|
||||
<!-- year separator -->
|
||||
<tr><td> </td><td> </td></tr>
|
||||
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Burnap02">Burnap02</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Steven R. Burnap, <i>Boost::any</i>,
|
||||
Kuro5hin, May 1, 2002. <A href="http://www.kuro5hin.org/story/2002/5/1/142321/9513">
|
||||
www.kuro5hin.org/story/2002/5/1/142321/9513</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Carbon02">Carbon02</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">David S?, <i>Boost : The handy library of
|
||||
handy libraries</i>. Kuro5hin, July 18, 2002. <A href="http://www.kuro5hin.org/story/2002/7/18/3313/01429">
|
||||
www.kuro5hin.org/story/2002/7/18/3313/01429</A>
|
||||
</TD>
|
||||
</TR>
|
||||
<tr>
|
||||
<td vAlign="top" align="left" width="16%"><b>[<a name="Curran02">Curran02</a>]</b></td>
|
||||
<td vAlign="top" align="left" width="84%">James Curran, <i>Access Raw Data with
|
||||
Performance Counters in Visual C++</i>. DevX.com, October, 2002. <a href="http://www.devx.com/cplus/article/7951">
|
||||
www.devx.com/cplus/article/7951</a>
|
||||
<br>Devotes several paragraphs to <code>boost::shared_ptr<></code>.
|
||||
</td>
|
||||
</tr>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Siek02b">Siek02b</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Jeremy G. Siek, <i>Internet Packet Routing
|
||||
with the Boost Graph Library</i>. InformIT, March 1, 2002. <A href="http://tinyurl.com/26dwj">
|
||||
tinyurl.com/26dwj</A></TD>
|
||||
</TR>
|
||||
|
||||
<!-- year separator -->
|
||||
<tr><td> </td><td> </td></tr>
|
||||
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Casad03">Casad03</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Joe Casad, <i>Introducing the Boost Corner</i>.
|
||||
C/C++ Users Journal, August, 2003. <A href="http://www.cuj.com/documents/s=8470/cuj0308boostcorner/">
|
||||
www.cuj.com/documents/s=8470/cuj0308boostcorner/</A>
|
||||
</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Lischner03">Lischner03</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">
|
||||
Ray Lischner, <i>C++: Beyond the Standard Library</i>. O'Reilly Network, May 6,
|
||||
2003. <A href="http://www.oreillynet.com/lpt/a/3683">www.oreillynet.com/lpt/a/3683</A>
|
||||
<br>Mentions <CODE>tuples, shared_ptr, lambda, spirit</CODE>.
|
||||
</TD>
|
||||
</TR>
|
||||
|
||||
<!-- year separator -->
|
||||
<tr><td> </td><td> </td></tr>
|
||||
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Inaba04a">Inaba04a</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Kazuhiro Inaba, <i>Let's Boost</i>. 2004. <A href="http://www.kmonos.net/alang/boost/">
|
||||
www.kmonos.net/alang/boost/</A></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Stein04">Stein04</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">
|
||||
<P>Sebastian Stein, <i>How to use Boost Test for automated testing</i>. 2004. <A href="http://www.hpfsc.de/boosttest/">
|
||||
www.hpfsc.de/boosttest/</A></P>
|
||||
</TD>
|
||||
</TR>
|
||||
|
||||
<!-- year separator -->
|
||||
<tr><td> </td><td> </td></tr>
|
||||
|
||||
<TR>
|
||||
<TD vAlign="top" align="left" width="16%"><b>[<a name="Lindrud05">Lindrud05</a>]</b></TD>
|
||||
<TD vAlign="top" align="left" width="84%">Jarl Lindrud, <i>RMI for C++</i>.
|
||||
The Code Project, April 11, 2005. <A href="http://www.codeproject.com/threads/RMI_For_Cpp.asp">www.codeproject.com/threads/RMI_For_Cpp.asp</A>
|
||||
<br>Uses Boost.Serialization.</TD>
|
||||
</TR>
|
||||
</table>
|
||||
<h2>How to <a name="update">update</a> this page</h2>
|
||||
<p>Please help us keep this page updated - users can post new citations to the
|
||||
mailing list, while Boost developers should update the page directly in CVS.</p>
|
||||
<ul>
|
||||
<li>
|
||||
If a publication is available both in print and online, cite it in the
|
||||
appropriate <i>print</i>
|
||||
section, with a hyperlink to the online version.
|
||||
<li>
|
||||
Bookmark the contents of [...] in the first column to make it easy to link to
|
||||
the entry.
|
||||
<li>
|
||||
Identify the first entry an author has in a given year with just the two-digit
|
||||
year. Subsequent entries for the same author and year should have <b>a-z</b>
|
||||
appended.
|
||||
<li>
|
||||
Inside each section, entries are grouped by year and, within a year, alphabetically
|
||||
sorted by author name.
|
||||
<li>
|
||||
In the text, spell out absolute URL's so that printed versions of this page
|
||||
include the full URL.
|
||||
</li>
|
||||
</ul>
|
||||
<h2><a name="Acknowledgements">Acknowledgements</a></h2>
|
||||
<p>Fredrik Blomqvist provided many of the initial citations.</p>
|
||||
<hr>
|
||||
<p>Revised
|
||||
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
|
||||
17 September, 2005<!--webbot bot="Timestamp" endspan i-checksum="40409" --></p>
|
||||
<p>© Copyright Beman Dawes 2003</p>
|
||||
<p> Distributed under the Boost Software License, Version 1.0.
|
||||
(See accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or
|
||||
copy at <a href="http://www.boost.org/LICENSE_1_0.txt">www.boost.org/LICENSE_1_0.txt</a>)
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
@ -5,7 +5,7 @@ License, Version 1.0. (boostinspect:nolicense boostinspect:nocopyright)
|
||||
Aleksey Gurtovoy (agurtovoy@meta-comm.com)
|
||||
Andrei Alexandrescu (andrewalex - at - hotmail.com) (See Boost list message of August 12, 2004 11:06:58 AM EST)
|
||||
Andrew Lumsdaine ()
|
||||
Anthony Williams (anthony -at- justsoftwaresolutions.co.uk(
|
||||
Anthony Williams (anthony -at- justsoftwaresolutions.co.uk)
|
||||
Beman Dawes (bdawes@acm.org)
|
||||
Brad King (brad.king -at- kitware.com) (See Boost list message of Wed, 21 Jul 2004 11:15:46 -0400)
|
||||
Brian Osman (osman -at- vvisions.com) (See CVS log)
|
||||
@ -96,6 +96,9 @@ Trustees of Indiana University ()
|
||||
University of Notre Dame ()
|
||||
Vladimir Prus (ghost@cs.msu.su)
|
||||
William E. Kempf () (email to Beman Dawes, 9/14/2006 4:18 PM)
|
||||
Joerg Walter (jhr.walter - at - t-online.de : email to ublas mailing list Mon, 17 Sep 2007 10:17:08 +0200)
|
||||
Mathias Koch (mkoch - at - idesis.de 7 : email to boost-owner@lists.boost.org Sep 2007 13:20:09 +0200)
|
||||
|
||||
--- end ---
|
||||
|
||||
|
||||
|
820
boost_soc_06_overview.html
Normal file
820
boost_soc_06_overview.html
Normal file
@ -0,0 +1,820 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0.1 Transitional//EN">
|
||||
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||||
<title>An overview of Boost participation in
|
||||
Google Summer of Code™ 2006</title>
|
||||
<link rel="stylesheet" href="../boost.css" type="text/css">
|
||||
<style type="text/css">
|
||||
<!--
|
||||
table{
|
||||
PADDING-RIGHT: 2pt;
|
||||
BORDER-TOP: gray 1pt solid;
|
||||
DISPLAY: block;
|
||||
PADDING-LEFT: 2pt;
|
||||
PADDING-BOTTOM: 2pt;
|
||||
BORDER-LEFT: gray 1pt solid;
|
||||
MARGIN-RIGHT: 32pt;
|
||||
PADDING-TOP: 2pt;
|
||||
background-color: #EEEEEE;
|
||||
}
|
||||
td{
|
||||
BORDER-STYLE: solid;
|
||||
BORDER-WIDTH: 1pt;
|
||||
BORDER-LEFT: ;
|
||||
BORDER-RIGHT: gray 1pt solid;
|
||||
BORDER-TOP: ;
|
||||
BORDER-BOTTOM: gray 1pt solid;
|
||||
}
|
||||
th{color: #ffffff; background-color: #000000;}
|
||||
.odd_tr{background-color: #ffffff;}
|
||||
-->
|
||||
</style>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<img src="../boost.png" alt="boost.png (6308 bytes)" align="middle" width="277" height="86">
|
||||
<h1>An overview of Boost participation in
|
||||
Google Summer of Code™ 2006</h1>
|
||||
|
||||
<hr>
|
||||
|
||||
<p>
|
||||
For the second consecutive year, Google has conducted its
|
||||
<a href="http://code.google.com/soc/">Summer of Code™</a> initiative,
|
||||
a program by which student developers are sponsored for their contributions
|
||||
within open source organizations willing to mentor the participants. The 2006
|
||||
campaign has run between April and September, with active development work
|
||||
taking place between May 23 and August 21.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Around mid April, when the program had just started, some Boost members began
|
||||
considering the possibility to enter Summer of Code as a mentoring
|
||||
organization. Despite the lack of time and the fact that most of us were
|
||||
completely new to this initiative, Boost managed to successfully apply for
|
||||
the program. As a result ten projects were selected and mentored, most of
|
||||
which are expected to become full contributions to Boost in the near future.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
We give here a summary report of this experience, along with a short analysis
|
||||
of the main problems we found, so that we can work at solving them and do
|
||||
better next year.
|
||||
</p>
|
||||
|
||||
<h2>Contents</h2>
|
||||
|
||||
<ul>
|
||||
<li><a href="#how_the_program_works">How the program works</a>
|
||||
<ul>
|
||||
<li><a href="#2006_figures">2006 figures</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a href="#boost_participation">Boost participation</a>
|
||||
<ul>
|
||||
<li><a href="#application_and_process_selection">Application and
|
||||
process selection</a></li>
|
||||
<li><a href="#accepted_projects">Accepted projects</a></li>
|
||||
<li><a href="#development">Development</a></li>
|
||||
<li><a href="#results">Results</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a href="#analysis">Analysis</a>
|
||||
<ul>
|
||||
<li><a href="#boost_appeal">Boost appeal</a></li>
|
||||
<li><a href="#opportunities_lost">Opportunities lost?</a></li>
|
||||
<li><a href="#projects_startup">Projects startup</a></li>
|
||||
<li><a href="#ongoing_development">Ongoing development</a></li>
|
||||
<li><a href="#public_communication_issues">Public communication
|
||||
issues</a></li>
|
||||
<li><a href="#scope_of_projects">Scope of projects</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a href="#suggestions_for_improvement">Suggestions for improvement</a>
|
||||
<ul>
|
||||
<li><a href="#preparation">Preparation</a></li>
|
||||
<li><a href="#public_communication">Public communication</a></li>
|
||||
<li><a href="#project_management">Project management</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a href="#conclusions">Conclusions</a></li>
|
||||
<li><a href="#acknowledgements">Acknowledgements</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="how_the_program_works">How the program works</a></h2>
|
||||
|
||||
<p>
|
||||
There are three types of participants in Google Summer of Code:
|
||||
<ul>
|
||||
<li>Google itself acts as the funding partner and conducts the overall
|
||||
program.</li>
|
||||
<li>The open source organizations accepted into the program must designate
|
||||
people inside the organization who will act as project mentors.</li>
|
||||
<li>Students submit their project ideas and, if selected, work in
|
||||
collaboration with one of the mentoring organizations; upon successful
|
||||
completion of the project, students receive the full stipend for the
|
||||
program.</li>
|
||||
</ul>
|
||||
The program goes through the following stages:
|
||||
<ul>
|
||||
<li>Organization selection: those open source organizations willing to
|
||||
enter Summer of Code submit an expression of interest to Google, along
|
||||
with information Google uses for qualifying purposes. Selected organizations
|
||||
are publicly announced and each organization is expected to provide a pool
|
||||
of project ideas.</li>
|
||||
<li>Student selection: students willing to participate submit one or more
|
||||
project proposals, typically expanding on some of the ideas previously
|
||||
provided by the mentoring organizations. A student can apply several times
|
||||
and for different organizations, but ultimately can only be chosen for just
|
||||
one project. These proposals are routed by Google to the appropriate
|
||||
organizations, which must analyze them, rank them, and assign mentors to the
|
||||
most promising applications. Based on the information provided by mentoring
|
||||
organizations, Google issues the final list of accepted projects.</li>
|
||||
<li>Development: Students, guided by their assigned mentors, are expected to
|
||||
complete the projects in a period of three months. Google asks mentors for a
|
||||
mid-program review upon which continuation of the project depends.</li>
|
||||
<li>Final review: Once the development period is over, mentors are requested
|
||||
to inform Google on the results of the project, and determine whether students
|
||||
qualify to receive the full stipend.</li>
|
||||
</ul>
|
||||
</p>
|
||||
|
||||
<h3><a name="2006_figures">2006 figures</a></h3>
|
||||
|
||||
<p>
|
||||
The 2006 campaign of Google Summer of Code took place between April 14 and
|
||||
September 25. A total of 102 mentoring organizations participated. Of the 6,338
|
||||
applications submitted by 3,044 students around the globe, 630 were finally
|
||||
selected and funded. Google has spent more than US$3 million in student stipends
|
||||
and compensations to the mentoring organizations.
|
||||
</p>
|
||||
|
||||
<h2><a name="#boost_participation">Boost participation</a></h2>
|
||||
|
||||
<h3><a name="#application_and_process_selection">Application and
|
||||
process selection</a></h3>
|
||||
|
||||
<p>
|
||||
On April 14, the same day Google Summer of Code started, Julio M. Merino Vidal
|
||||
(later to become one of the selected students) sent a message encouraging Boost
|
||||
members to participate in this program as a mentoring organization. This call
|
||||
sparked the interest of the community; although time was already short for doing
|
||||
all the preparation labors, Boost moderators put rapidly themselves to work and
|
||||
conducted the preliminary registration steps. In the meantime, a Wiki page was
|
||||
grown with project ideas provided by Boost members, totalling more than twenty
|
||||
proposals.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
By the beginning of May Boost was officially accepted into the program and Boost
|
||||
moderators set out to form a group of mentors, selected on an invitation basis.
|
||||
As student selection is a delicate process, involving the assessment of individuals
|
||||
on their technical skills, all subsequent discussions were conducted by the
|
||||
selected mentors on a private mail list established for their collaboration.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
We were not prepared for the avalanche of student applications that followed. On
|
||||
day two after the application period was open, we had received three proposals;
|
||||
next day it was 14, and within a week the count exceeded 50. By the end of the
|
||||
application period the total number of proposals received was 174, which forced
|
||||
us to go through a very intensive ranking process and recruit additional mentors.
|
||||
Two rules were followed so as rationalize the process of selection among dozens
|
||||
of different proposals:
|
||||
<ul>
|
||||
<li>Where there were competing applications for the same project idea, only
|
||||
one were to be ultimately selected; so, no two projects with the same or very
|
||||
similar goals were accepted.</li>
|
||||
<li>Some of the applications built on a given Boost library (for instance, the
|
||||
Boost Graph Library is a frequent target for the addition of algorithms.) We
|
||||
limited the applications to a maximum of two per Boost library.</li>
|
||||
</ul>
|
||||
These rules have the combined effect of greatly reducing the number of eligible
|
||||
applications while at the same time distributing the accepted projects evenly
|
||||
across the space of ideas. Moreover, students with unique proposals, i.e. project
|
||||
ideas not coming from the pool originally presented by Boost, are at a
|
||||
competitive advantage.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The different proposals were classified according to its related technological
|
||||
area so that each cluster could be handled by an appointed mentor with the
|
||||
required expertise on the subject. Mentors submitted then "focus reports"
|
||||
summarizing the applications under their responsibility; these reports served as
|
||||
a first filter to help reduce the number of final applications to be evaluated
|
||||
jointly. Along the process, students with the most promising proposals were asked
|
||||
to refine their ideas and provide further information.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Although not enforced by the official rules, we agreed upon a one-to-one ratio
|
||||
of mentors to students, which ultimately marked a hard limit on the maximum number
|
||||
of eligible projects.
|
||||
</p>
|
||||
|
||||
<h3><a name="accepted_projects">Accepted projects</a></h3>
|
||||
|
||||
<p>
|
||||
Google accepted and funded the ten top-ranked projects endorsed by Boost. Of
|
||||
these, eight projects are libraries or library components targeted for future
|
||||
inclusion into Boost, while the remaining two consist of utility programs
|
||||
heavily relying on Boost.
|
||||
</p>
|
||||
|
||||
<blockquote>
|
||||
<b>C++ Coroutine Library</b>
|
||||
<br>
|
||||
Giovanni Piero Deretta, mentored by Eric Niebler.
|
||||
<br>
|
||||
Library for the management through a modern C++ interface of OS-provided
|
||||
coroutine facilities.
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<b>Concurrency Library</b>
|
||||
<br>
|
||||
Matthew Calabrese, mentored by David Abrahams.
|
||||
<br>
|
||||
STL-inspired generic framework for high-level specification and execution of
|
||||
parallelizable algorithms.
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<b>TR1 Math Special Functions</b>
|
||||
<br>
|
||||
Xiaogang Zhang, mentored by John Maddock.
|
||||
<br>
|
||||
Implementation of the 23 special mathematical functions specified in C++
|
||||
standard library extension proposal TR1.
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<b>The Boost.Process library</b>
|
||||
<br>
|
||||
Julio M. Merino Vidal, mentored by Jeff Garland.
|
||||
<br>
|
||||
Portable library for process launching and basic management.
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<b>Out-of-Core Graphs and Graph Algorithms</b>
|
||||
<br>
|
||||
Stéphane Zampelli, mentored by Jeremy Siek.
|
||||
<br>
|
||||
Extension of the Boost Graph Library to deal with out-of-core structures,
|
||||
i.e. data sets too large to be kept in main memory at once.
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<b>MISC (M)ulti (I)ndex (S)pecialized (C)ontainers</b>
|
||||
<br>
|
||||
Matías Capeletto, mentored by Joaquín M López Muñoz.
|
||||
<br>
|
||||
Families of specialized containers internally based on Boost.MultiIndex.
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<b>Generic Tree Container</b>
|
||||
<br>
|
||||
Bernhard Reiter, mentored by René Rivera.
|
||||
<br>
|
||||
Design and implementation of a family of STL-compatible tree containers.
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<b>Viewer utility for FSMs</b>
|
||||
<br>
|
||||
Ioana Tibuleac, mentored by Andreas Huber Dönni.
|
||||
<br>
|
||||
Utility program for the visualization of finite state machines (FSMs) specified
|
||||
with Boost.Statechart.
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<b>Modular C++ preprocessor, using Boost.Spirit</b>
|
||||
<br>
|
||||
Hermanpreet 'Lally' Singh, mentored by Joel de Guzman.
|
||||
<br>
|
||||
Implementation with Boost.Spirit and Boost.Wave of a front-end translator
|
||||
from Modular C++ (as specified in a proposal to add modules to C++ by Daveed
|
||||
Vandevoorde) to standard C++.
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<b>Implementing a state of the art Mincut/Maxflow algorithm.</b>
|
||||
<br>
|
||||
Stephan Diederich, mentored by Douglas Gregor.
|
||||
<br>
|
||||
Implementation of a fast mincut/maxflow routine for the Boost Graph Library
|
||||
based on a new algorithm devised by Vladimir Kolmogorov.
|
||||
</blockquote>
|
||||
|
||||
<h3><a name="development">Development</a></h3>
|
||||
|
||||
<p>
|
||||
Two main facilities were set up to assist students and mentors during the
|
||||
development phase: a mailing list and a Trac/SVN project management system
|
||||
with separate directories for each project. One of the students, Matías
|
||||
Capeletto, out of personal initiative registered a Google Group aimed at giving
|
||||
students with Boost a place for informal interaction and discussion of common
|
||||
problems.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
After the initial warm-up period, each student-mentor pair performed development
|
||||
work mostly privately. The usage of the Boost mailing lists was scarce, and
|
||||
only by the end of the program did some students publicly announced their results.
|
||||
</p>
|
||||
|
||||
<h3><a name="results">Results</a></h3>
|
||||
|
||||
<p>
|
||||
By the date the development period was officially closed, the status of the
|
||||
different projects was as follows:
|
||||
<ul>
|
||||
<li>Seven projects were completed or nearly completed and the students are
|
||||
expected to ask for a formal review within 2006 or early 2007. Four of these
|
||||
projects necessitated a goal reorientation during development, basically
|
||||
because the original plan was too ambitious for three months. Most of the
|
||||
projects are still in active development during the months following the
|
||||
Summer of Code program.</li>
|
||||
<li>Two projects did not reach the planned goals, but nevertheless produced
|
||||
useful material that could be expanded outside of the Summer of Code
|
||||
program.</li>
|
||||
<li>One project was abandoned shortly after the midterm review. The reasons
|
||||
for the abandonment are unknown.</li>
|
||||
</ul>
|
||||
The results of all the projects can be consulted online at the dedicated
|
||||
<a href="https://www.boost-consulting.com:8443/trac/soc/browser/boost/soc/2006">Trac
|
||||
site</a>.
|
||||
</p>
|
||||
|
||||
<h2><a name="analysis">Analysis</a></h2>
|
||||
|
||||
<p>
|
||||
We examine the various stages of Boost participation in Summer of Code, with an
|
||||
emphasis on discovering opportunities for improvement.
|
||||
</p>
|
||||
|
||||
<h3><a name="boost_appeal">Boost appeal</a></h3>
|
||||
|
||||
<p>
|
||||
In a mid project
|
||||
<a href="http://code.google.com/soc/GSoC2006Statistics.pdf">presentation at OSCON
|
||||
2006</a>, Chris DiBona from Google provided some data about the organizations
|
||||
which received the most applications:
|
||||
</p>
|
||||
|
||||
<p align="center">
|
||||
<table cellspacing="0">
|
||||
<tr>
|
||||
<th align="left">Organization</th>
|
||||
<th>No of applications</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>KDE</td>
|
||||
<td align="center">244</td>
|
||||
</tr>
|
||||
<tr class="odd_tr">
|
||||
<td>Ubuntu & Bazaar</td>
|
||||
<td align="center">236</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Python Software Foundation</td>
|
||||
<td align="center">212</td>
|
||||
</tr>
|
||||
<tr class="odd_tr">
|
||||
<td>GNOME</td>
|
||||
<td align="center">199</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Apache Software Foundation</td>
|
||||
<td align="center">190</td>
|
||||
</tr>
|
||||
<tr class="odd_tr">
|
||||
<td><b>Boost</b></td>
|
||||
<td align="center"><b>174</b></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Gaim</td>
|
||||
<td align="center">152</td>
|
||||
</tr>
|
||||
<tr class="odd_tr">
|
||||
<td>The GNU Project</td>
|
||||
<td align="center">148</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Drupal</td>
|
||||
<td align="center">146</td>
|
||||
</tr>
|
||||
</table>
|
||||
</p>
|
||||
<blockquote style="FONT-SIZE: 75%;">
|
||||
The numbers shown here have been estimated from a chart included in the
|
||||
presentation slides. This chart contains an additional column labeled "Google"
|
||||
which actually accounts for the applications dismissed because of their low
|
||||
quality.
|
||||
</blockquote>
|
||||
|
||||
<p>
|
||||
The fact that Boost is ranked the sixth most attractive organization out of a
|
||||
total of 102 was entirely unexpected, especially considering the wide popularity
|
||||
of the rest of top-rated organizations. There is a more or less implicit
|
||||
consensus among Boost members that ours is a relatively niche project, known for
|
||||
its quality standards by seasoned C++ practitioners, but with a limited penetration
|
||||
among entry level programmers: maybe the figures above should make us reconsider
|
||||
this assumption. A cursory examination of the applications submitted to Boost reveals
|
||||
that most applicants were regular users of Boost: many cite the Boost status among
|
||||
the C++ community as an appealing factor in order to apply.
|
||||
</p>
|
||||
|
||||
<h3><a name="opportunities_lost">Opportunities lost?</a></h3>
|
||||
|
||||
<p>
|
||||
If we look at the number of funded projects with respect to the applications received,
|
||||
figures are not so favorable to Boost.</p>
|
||||
|
||||
<p align="center">
|
||||
<table cellspacing="0">
|
||||
<tr>
|
||||
<th align="left">Organization</th>
|
||||
<th>No of projects</th>
|
||||
<th>Project/app ratio</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>KDE</td>
|
||||
<td align="center">24</td>
|
||||
<td align="center">9.8 %</td>
|
||||
</tr>
|
||||
<tr class="odd_tr">
|
||||
<td>Ubuntu & Bazaar</td>
|
||||
<td align="center">22</td>
|
||||
<td align="center">9.3 %</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Python Software Foundation</td>
|
||||
<td align="center">23</td>
|
||||
<td align="center">10.8 %</td>
|
||||
</tr>
|
||||
<tr class="odd_tr">
|
||||
<td>GNOME</td>
|
||||
<td align="center">19</td>
|
||||
<td align="center">9.5 %</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Apache Software Foundation</td>
|
||||
<td align="center">27</td>
|
||||
<td align="center">14.2 %</td>
|
||||
</tr>
|
||||
<tr class="odd_tr">
|
||||
<td><b>Boost</b></td>
|
||||
<td align="center"><b>10</b></td>
|
||||
<td align="center"><b>5.7 %</b></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Gaim</td>
|
||||
<td align="center">8</td>
|
||||
<td align="center">5.3 %</td>
|
||||
</tr>
|
||||
<tr class="odd_tr">
|
||||
<td>The GNU Project</td>
|
||||
<td align="center">10</td>
|
||||
<td align="center">6.8 %</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Drupal</td>
|
||||
<td align="center">14</td>
|
||||
<td align="center">9.6 %</td>
|
||||
</tr>
|
||||
</table>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
It turns out that the project/application ratio for almost any other organization
|
||||
among the top nine is considerably higher than that of Boost. As it happens, Google
|
||||
initially requested that organizations submitted the maximum number of projects they
|
||||
felt they could cope with, and we got funding for exactly what we aimed for, so the
|
||||
limiting factor lies entirely on Boost's side.
|
||||
</p>
|
||||
|
||||
<h3><a name="projects_startup">Projects startup</a></h3>
|
||||
|
||||
<p>
|
||||
Contributing to Boost relies on a fair number of guidelines and protocols for
|
||||
coding, documentation, testing and maintenance. Many of the required tools are
|
||||
exclusively used within Boost, and some of them are not trivial, like for instance
|
||||
Boost.Build. Although the Boost web site contains information about all these tools
|
||||
and procedures, this intelligence is scattered through unrelated pages and sometimes
|
||||
is very hard to come by.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
So, there is a good deal of expertise required to begin working at Boost. Some
|
||||
students have reported on startup difficulties getting to know these details and
|
||||
familiarizing themselves with the tools, most notably <code>bjam</code> and Quickbook. Each
|
||||
student overcome the startup difficulties on their own or resorting to their
|
||||
mentors (see the section on <a href="#public_communication_issues">public
|
||||
communication issues</a>).
|
||||
</p>
|
||||
|
||||
<h3><a name="ongoing_development">Ongoing development</a></h3>
|
||||
|
||||
<p>
|
||||
Once students got past the startup stage, most projects advanced without serious
|
||||
complications. In the majority of cases, it was realized at some point during
|
||||
the development that there was no time to complete it. Some participants had to
|
||||
redefine the goals in an effort to keep the project within schedule, while others
|
||||
simply decided that they would continue working after the official deadline of
|
||||
Summer of Code.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The information flow between each student and their mentor was usually reported
|
||||
by both parties to be satisfactory. The projects suffering from lack of
|
||||
communication have been precisely those yielding the poorest results. In general,
|
||||
mentors have not felt overwhelmed by requests from their students, and even in a
|
||||
couple of cases the projects were run practically unattendedly. This fact is
|
||||
witness to the high competence of the students recruited into the program.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The degree of usage of the Trac/SVN system has varied. Some students did frequent
|
||||
updates, while others have just used the repository to dump the final results for
|
||||
the official submission to Google.
|
||||
</p>
|
||||
|
||||
<h3><a name="public_communication_issues">Public communication
|
||||
issues</a></h3>
|
||||
|
||||
<p>
|
||||
Students and mentors had at their disposal three different forums for the public
|
||||
interchange of information and support:
|
||||
<ul>
|
||||
<li>Boost public lists, especially the developers and users lists.</li>
|
||||
<li>A dedicated mailing list reaching all students and mentors working at
|
||||
Summer of Code in Boost.</li>
|
||||
<li>A more casual Google Group, set up by one of the students, aimed at
|
||||
providing the participants with a place for socializing and resolution of
|
||||
common problems.</li>
|
||||
</ul>
|
||||
Despite this abundance of resources, there was an almost complete lack of group
|
||||
communication among all the parties involved and between these and the larger
|
||||
Boost community. Seemingly, students were satisfied to pursue their activities by
|
||||
relying on support from their mentors alone. This circumstance has prevented
|
||||
Boost members from enriching the initiative by offering their experience and
|
||||
insight, and has possibly led students to the false impression that contributing
|
||||
to Boost proceeds in a predictable linear path from requisites to completion of
|
||||
the work. When asked about their not engaging in public communication, the students
|
||||
gave vague justifications that can be classified into the following:
|
||||
<ul>
|
||||
<li>Doubts were deemed too technical or specific to be worth raising in
|
||||
public.</li>
|
||||
<li>A crave for perfectionism detracted students from asking or submitting work
|
||||
in progress until they felt their material looked good enough.</li>
|
||||
<li>Shyness: some students probably lacked previous experience communicating in
|
||||
public, and most are not English native speakers, which could also be a
|
||||
limiting factor.</li>
|
||||
</ul>
|
||||
Although students did not identify the following as a reason not to go public, it
|
||||
is likely that many of them did not feel the need given the readily access to their
|
||||
mentors they enjoyed. It is easy to grow used to such a dedicated source of support
|
||||
and neglect resorting to other resources. Mentors should have encouraged their
|
||||
students to pursue the public discussion of projects, which constitutes one of the
|
||||
pillars of Boost renowned quality.
|
||||
</p>
|
||||
|
||||
<h3><a name="scope_of_projects">Scope of projects</a></h3>
|
||||
|
||||
<p>
|
||||
In hindsight, it has become apparent that most projects were too ambitious to be
|
||||
completed within the three months of duration of the program, and even those that
|
||||
were considered a success will need weeks or months of polishing up before the
|
||||
material is ready for a formal review. In contrast with other organizations
|
||||
participating in the Summer of Code program, Boost has as of this writing included
|
||||
no results into its code base. No formal review for any project has been requested
|
||||
yet, either.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
These scope issues are very dependent on the particular type of project. We can
|
||||
classify the Boost projects for Summer of Code as follows:
|
||||
<ul>
|
||||
<li>Full-fledged libraries,</li>
|
||||
<li>additions to existing Boost libraries,</li>
|
||||
<li>utilities and tool projects using Boost.</li>
|
||||
</ul>
|
||||
Of these, additions (like for instance the mincut/maxflow algorithm for BGL by
|
||||
Stephan Diederich) are the most suitable for completion in a short period of time:
|
||||
most of the preparation work is already done, and the student has clear guides as
|
||||
to what coding and documentation standards to follow. Also, these projects need
|
||||
not undergo a formal review, since it is the responsibility of the hosting library
|
||||
author to review the code and include it within her discretion. Utility projects
|
||||
seem also suitable for small timeframes, though most project proposals and requests
|
||||
are naturally oriented to contributions of actual code to the Boost project.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
As for those projects involving the design and realization of full-fledged
|
||||
libraries, there is little hope that the goals and scope can be kept modest enough
|
||||
for a three-month schedule. Boost candidate libraries developed by professional
|
||||
authors usually take much longer than three months to be accepted; some libraries
|
||||
have been evolving through several <i>years</i> before being included into Boost.
|
||||
So, the best we can hope for if we are to support the realization of library projects
|
||||
for Boost inside Summer of Code is that the results by the end of the program can
|
||||
be evaluated to constitute a viable <i>potential</i> contribution to Boost. When this is
|
||||
the case, it is crucial that the student commits to further working on the project
|
||||
up to completion and formal review. Perhaps more important than getting libraries
|
||||
coded is to engage new authors into a long-term relationship with the Boost project.
|
||||
</p>
|
||||
|
||||
<h2><a name="suggestions_for_improvement">Suggestions for improvement</a></h2>
|
||||
|
||||
<p>
|
||||
The following proposals aim to alleviate some of the problems we have identified
|
||||
during the development of Summer of Code within Boost. These action points are
|
||||
related only to the issues found in connection with Boost: we are not addressing
|
||||
other areas of improvement associated to the Summer of Code program itself.
|
||||
</p>
|
||||
|
||||
<h3><a name="preparation">Preparation</a></h3>
|
||||
|
||||
<p>
|
||||
Much work can be done before the actual program begins. The following preparation
|
||||
activities can already be launched:
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Create a pool of ideas for projects.</b> This action will provide valuable extra
|
||||
time for evaluation and refining of ideas before the Summer of Code begins.
|
||||
The experience has shown that those projects with more preparation work, especially
|
||||
in the area of design, were ultimately more successful. The pool can also be used
|
||||
to retain interesting ideas that arise at the mailing lists and very often are
|
||||
not given proper attention and become abandoned.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Create a student pool.</b> Prior involvement with Boost is clearly an advantage
|
||||
both in the selection phase and later during project development. Those students
|
||||
with a serious interest in participating in Summer of Code with Boost can enter
|
||||
the pool and begin exploring ideas and interacting with the community well in
|
||||
advance of the summer, so as to put themselves in a favorable position for the
|
||||
selection. Advertisement for the student pool can be initiated in the beginning of
|
||||
2007 through the usual channels (web site and mailing lists): additionally, Boost
|
||||
members involved with the University can spread this information locally and help
|
||||
raise the interest of students in their environment.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Create a mentor pool.</b> Given the rush with which Boost entered the 2006
|
||||
Summer of Code campaign, the invitation of mentors has to be done on an on-demand
|
||||
basis as it became all too evident that the task was growing bigger and bigger.
|
||||
It is important that the organization is better prepared next year so that a
|
||||
number of people with the ability and will to participate as Boost mentors are
|
||||
identified in advance.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Prepare a startup package.</b> In order to facilitate the initial period of
|
||||
getting familiarized with the various Boost guidelines, protocols and tools, it
|
||||
would be extremely useful to prepare a compilation of startup material for
|
||||
students. This package can consist of a single document gathering the currently
|
||||
dispersed information, or go beyond this and provide some bundle of documentation
|
||||
and pre-built tools, an approach that one of the students is currently working on.
|
||||
</p>
|
||||
|
||||
<h3><a name="public_communication">Public communication</a></h3>
|
||||
|
||||
<p>
|
||||
It is crucial that students get involved with the community as soon as possible
|
||||
and grow to appreciate the advantages of public development with respect to
|
||||
solitary coding.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Mandate (bi)weekly reports.</b> These reports should be directed to the public
|
||||
mailing lists so as to give all Boost members an opportunity to follow the work
|
||||
in progress and contribute. Reporting has the extra benefit for students of
|
||||
forcing them to reflect on their own work periodically and struggle with the
|
||||
often difficult task of presenting their ideas to others.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Conduct student-mentor exclusively through public channels.</b> This might be
|
||||
too drastic a policy, as some matters need privacy, and depending on the amount
|
||||
of information exchanged flooding problems may arise. Less severe variations
|
||||
involve allowing for some private interchange at the mentors' discretion and
|
||||
moving this kind of communication to a dedicated public mailing list different
|
||||
from the general ones.
|
||||
</p>
|
||||
|
||||
<h3><a name="project_management">Project management</a></h3>
|
||||
|
||||
<p>
|
||||
The two most important issues to improve upon with respect to the management are:
|
||||
<ul>
|
||||
<li>Project scope must be kept under control,</li>
|
||||
<li>The progress has to be publicly visible, so that problems of scope,
|
||||
design and/or schedule can be more easily detected.</li>
|
||||
</ul>
|
||||
Some of the proposals in this section are not to be regarded as strict rules,
|
||||
but rather as general guidelines to be kept in mind by students and encouraged
|
||||
by mentors.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Create a best practices document.</b> This document can serve as a guideline
|
||||
for project management, an area in which Boost traditionally imposes no
|
||||
requirements. Students might lack the expertise in this area that is usually
|
||||
taken for granted in the traditional model where contributions to Boost are
|
||||
made by professional programmers.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Mandate a design phase.</b> Having a concrete design set up and clearly
|
||||
described early in the project will help estimate the necessary effort for
|
||||
completion of the work. This is also an opportunity for public discussion.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Maintain code, docs and tests in parallel.</b> All too often, novice
|
||||
programmers do the coding in one fell swoop and only then move to testing and
|
||||
documenting their work. This is unacceptable by all current methodology
|
||||
standards, and can result in serious underestimations of the time to
|
||||
completion.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Encourage the KISS principle.</b> It is much better to finish a simpler library
|
||||
and then iteratively evolve it, once it has been exposed to public scrutiny and
|
||||
usage.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>More Trac updates.</b> The repository should be viewed as an everyday work
|
||||
tool, not only as the place into which to dump the final results. Updating often
|
||||
leads to more visibility of the work by the mentor and the public in general.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Informal reviews.</b> The typical Summer of Code Boost project will not be
|
||||
completed by the official deadline, as have been discussed earlier. To somehow
|
||||
officialize the work done within the Summer of Code proper, and also to allow
|
||||
the students to reach some sort of psychological milestone, informal reviews can
|
||||
be instituted where Boost members evaluate the work done at then end of Summer
|
||||
of Code.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<b>Engage students.</b> This experience has shown that it is possible to guide
|
||||
willing and bright students to the competence levels required for contributing
|
||||
to Boost. The best possible outcome of Summer of Code campaigns are the
|
||||
incorporation of new people into the circle of Boost active contributors. Strive
|
||||
to make the students commit to Boost.
|
||||
</p>
|
||||
|
||||
<h2><a name="conclusions">Conclusions</a></h2>
|
||||
|
||||
<p>
|
||||
Despite the lack of previous experience in Boost, our participation in Google
|
||||
Summer of Code has been extremely fruitful: much useful material has been produced,
|
||||
and, perhaps more importantly, some of the students are likely to commit on a
|
||||
long-term basis and grow to be regular Boost contributors. Traditionally, becoming
|
||||
a productive Boost author has a very high entry barrier due to the extreme quality
|
||||
standards, lack of public support and the very specific culture of the project.
|
||||
The appeal of Summer of Code itself and the possibility of being gently mentored
|
||||
into the world of Boost have most likely been key factors in lowering this entry
|
||||
barrier.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The process has not been without some difficulties, either, as it was expected of
|
||||
a newcomer organization as Boost. We have tried to identify in this paper the
|
||||
areas of improvement and suggest specific actions so that the upcoming Google
|
||||
Summer of Code 2007 can be an even more rewarding experience.
|
||||
</p>
|
||||
|
||||
<h2><a name="acknowledgements">Acknowledgements</a></h2>
|
||||
|
||||
<p>
|
||||
This paper couldn't have been written without the numerous reports and contributions
|
||||
kindly provided by Boost students and mentors: Many thanks to all the participants
|
||||
for sharing their experiences with me. Thank you also to the people at Google who
|
||||
have promoted and conducted the Summer of Code initiative.
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
|
||||
<p>Revised October 17th 2006</p>
|
||||
|
||||
<p>© Copyright 2006 Joaquín M López Muñoz.
|
||||
Distributed under the Boost Software
|
||||
License, Version 1.0. (See accompanying file <a href="../LICENSE_1_0.txt">
|
||||
LICENSE_1_0.txt</a> or copy at <a href="http://www.boost.org/LICENSE_1_0.txt">
|
||||
http://www.boost.org/LICENSE_1_0.txt</a>)
|
||||
</p>
|
||||
|
||||
</body>
|
||||
</html>
|
394
borland_cpp.html
394
borland_cpp.html
@ -1,394 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Language" content="en-us">
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
|
||||
|
||||
<title>Portability Hints: Borland C++ 5.5.1</title>
|
||||
</head>
|
||||
|
||||
<body bgcolor="#FFFFFF" text="#000000">
|
||||
<table border="1" bgcolor="#007F7F" cellpadding="2" summary="">
|
||||
<tr>
|
||||
<td bgcolor="#FFFFFF"><img src="../boost.png" alt=
|
||||
"boost.png (6897 bytes)" width="277" height="86"></td>
|
||||
|
||||
<td><a href="../index.htm"><font face="Arial,Helvetica" color=
|
||||
"#FFFFFF"><big>Home</big></font></a></td>
|
||||
|
||||
<td><a href="../libs/libraries.htm"><font face="Arial,Helvetica" color=
|
||||
"#FFFFFF"><big>Libraries</big></font></a></td>
|
||||
|
||||
<td><a href="../people/people.htm"><font face="Arial,Helvetica" color=
|
||||
"#FFFFFF"><big>People</big></font></a></td>
|
||||
|
||||
<td><a href="faq.htm"><font face="Arial,Helvetica" color=
|
||||
"#FFFFFF"><big>FAQ</big></font></a></td>
|
||||
|
||||
<td><a href="index.htm"><font face="Arial,Helvetica" color=
|
||||
"#FFFFFF"><big>More</big></font></a></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>Portability Hints: Borland C++ 5.5.1</h1>
|
||||
|
||||
<p>It is a general aim for boost libraries to be <a href=
|
||||
"lib_guide.htm#Portability">portable</a>. 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.</p>
|
||||
|
||||
<p>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 <a href=
|
||||
"http://www.borland.com/">http://www.borland.com/</a>.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<h2>Preprocessor symbol</h2>
|
||||
|
||||
<p>The preprocessor symbol <code>__BORLANDC__</code> 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.</p>
|
||||
|
||||
<table border="1" summary="">
|
||||
<tr>
|
||||
<th>Compiler</th>
|
||||
|
||||
<th><code>__BORLANDC__</code> value</th>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Borland C++ Builder 4</td>
|
||||
|
||||
<td>0x0540</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Borland C++ Builder 5</td>
|
||||
|
||||
<td>0x0550</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Borland C++ 5.5</td>
|
||||
|
||||
<td>0x0550</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Borland C++ 5.5.1</td>
|
||||
|
||||
<td>0x0551</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Borland C++ Builder 6</td>
|
||||
|
||||
<td>0x0560</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h2>Core Language</h2>
|
||||
|
||||
<h3>[using-directive] Mixing <code>using</code>-declarations and
|
||||
<code>using</code>-directives</h3>
|
||||
|
||||
<p>Mixing <code>using</code>-directives (which refer to whole namespaces)
|
||||
and namespace-level <code>using</code>-declarations (which refer to
|
||||
individual identifiers within foreign namespaces) causes ambiguities where
|
||||
there are none. The following code fragment illustrates this:</p>
|
||||
<pre>
|
||||
namespace N {
|
||||
int x();
|
||||
}
|
||||
|
||||
using N::x;
|
||||
using namespace N;
|
||||
|
||||
int main()
|
||||
{
|
||||
&x; // Ambiguous overload
|
||||
}
|
||||
</pre>
|
||||
|
||||
<h3>[using template] <code>using</code>-declarations for class
|
||||
templates</h3>
|
||||
|
||||
<p>Identifiers for class templates can be used as arguments to
|
||||
<code>using</code>-declarations as any other identifier. However, the
|
||||
following code fails to compile with Borland C++:</p>
|
||||
<pre>
|
||||
template<class T>
|
||||
class X { };
|
||||
|
||||
namespace N
|
||||
{
|
||||
// "cannot use template 'X<T>' without specifying specialization parameters"
|
||||
using ::X;
|
||||
};
|
||||
</pre>
|
||||
|
||||
<h3>[template const arg] Deduction of constant arguments to function
|
||||
templates</h3>
|
||||
|
||||
<p>Template function type deduction should omit top-level constness.
|
||||
However, this code fragment instantiates "f<const int>(int)":</p>
|
||||
<pre>
|
||||
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);
|
||||
}
|
||||
</pre>
|
||||
|
||||
<h3>[function address] Resolving addresses of overloaded functions</h3>
|
||||
|
||||
<p>Addresses of overloaded functions are not in all contexts properly
|
||||
resolved (std:13.4 [over.over]); here is a small example:</p>
|
||||
<pre>
|
||||
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)
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p><strong>Workaround:</strong> Always use C-style casts when determining
|
||||
addresses of (potentially) overloaded functions.</p>
|
||||
|
||||
<h3>[string conversion] Converting <code>const char *</code> to
|
||||
<code>std::string</code></h3>
|
||||
|
||||
<p>Implicitly converting <code>const char *</code> parameters to
|
||||
<code>std::string</code> arguments fails if template functions are
|
||||
explicitly instantiated (it works in the usual cases, though):</p>
|
||||
<pre>
|
||||
#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 *)"
|
||||
}
|
||||
|
||||
</pre>
|
||||
|
||||
<p><strong>Workaround:</strong> 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 <code>std::string</code> or declare the
|
||||
template function as taking a <code>const char *</code> parameter.</p>
|
||||
|
||||
<h3>[template value defaults] Dependent default arguments for template
|
||||
value parameters</h3>
|
||||
|
||||
<p>Template value parameters which default to an expression dependent on
|
||||
previous template parameters don't work:</p>
|
||||
<pre>
|
||||
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;
|
||||
}
|
||||
|
||||
</pre>
|
||||
|
||||
<p><strong>Workaround:</strong> If the relevant non-type template parameter
|
||||
is an implementation detail, use inheritance and a fully qualified
|
||||
identifier (for example, ::N::A<T>::value).</p>
|
||||
|
||||
<h3>[function partial ordering] Partial ordering of function templates</h3>
|
||||
|
||||
<p>Partial ordering of function templates, as described in std:14.5.5.2
|
||||
[temp.func.order], does not work:</p>
|
||||
<pre>
|
||||
#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)
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p><strong>Workaround:</strong> Declare all such functions uniformly as
|
||||
either taking a value or a reference parameter.</p>
|
||||
|
||||
<h3>[instantiate memfun ptr] Instantiation with member function
|
||||
pointer</h3>
|
||||
|
||||
<p>When directly instantiating a template with some member function
|
||||
pointer, which is itself dependent on some template parameter, the compiler
|
||||
cannot cope:</p>
|
||||
<pre>
|
||||
template<class U> class C { };
|
||||
template<class T>
|
||||
class A
|
||||
{
|
||||
static const int v = C<void (T::*)()>::value;
|
||||
};
|
||||
</pre>
|
||||
|
||||
<p><strong>Workaround:</strong> Use an intermediate
|
||||
<code>typedef</code>:</p>
|
||||
<pre>
|
||||
template<class U> class C { };
|
||||
template<class T>
|
||||
class A
|
||||
{
|
||||
typedef void (T::*my_type)();
|
||||
static const int v = C<my_type>::value;
|
||||
};
|
||||
</pre>
|
||||
|
||||
<p>(Extracted from e-mail exchange of David Abrahams, Fernando Cacciola,
|
||||
and Peter Dimov; not actually tested.)</p>
|
||||
|
||||
<h2>Library</h2>
|
||||
|
||||
<h3>[cmath.abs] Function <code>double std::abs(double)</code> missing</h3>
|
||||
|
||||
<p>The function <code>double std::abs(double)</code> should be defined
|
||||
(std:26.5-5 [lib.c.math]), but it is not:</p>
|
||||
<pre>
|
||||
#include <cmath>
|
||||
|
||||
int main()
|
||||
{
|
||||
double (*p)(double) = std::abs; // error
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>Note that <code>int std::abs(int)</code> will be used without warning if
|
||||
you write <code>std::abs(5.1)</code>.</p>
|
||||
|
||||
<p>Similar remarks apply to seemingly all of the other standard math
|
||||
functions, where Borland C++ fails to provide <code>float</code> and
|
||||
<code>long double</code> overloads.</p>
|
||||
|
||||
<p><strong>Workaround:</strong> Use <code>std::fabs</code> instead if type
|
||||
genericity is not required.</p>
|
||||
|
||||
<h2>Appendix: Additional issues with Borland C++ version 5.5</h2>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<h3>[inline friend] Inline friend functions in template classes</h3>
|
||||
|
||||
<p>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:</p>
|
||||
<pre>
|
||||
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;
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>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].</p>
|
||||
<hr>
|
||||
|
||||
<p><a href="http://validator.w3.org/check?uri=referer"><img border="0" src=
|
||||
"http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01 Transitional"
|
||||
height="31" width="88"></a></p>
|
||||
|
||||
<p>Revised
|
||||
<!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan -->03
|
||||
December, 2006<!--webbot bot="Timestamp" endspan i-checksum="38512" --></p>
|
||||
|
||||
<p><i>Copyright © 2000-2002 <a href="../people/jens_maurer.htm">Jens
|
||||
Maurer</a></i></p>
|
||||
|
||||
<p><i>Distributed under the Boost Software License, Version 1.0. (See
|
||||
accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy
|
||||
at <a href=
|
||||
"http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>)</i></p>
|
||||
</body>
|
||||
</html>
|
118
bugs.htm
118
bugs.htm
@ -1,118 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>
|
||||
<meta http-equiv="Content-Language" content="en-us">
|
||||
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
||||
|
||||
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
||||
|
||||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||||
<title>Bugs</title>
|
||||
</head>
|
||||
|
||||
|
||||
<body bgcolor="#ffffff" text="#000000">
|
||||
|
||||
<table border="1" bgcolor="#007f7f" cellpadding="2">
|
||||
|
||||
<tbody><tr>
|
||||
<td bgcolor="#ffffff">
|
||||
<img src="../boost.png" alt="boost.png (6897 bytes)" width="277" height="86"></td>
|
||||
<td><a href="../index.htm"><font face="Arial" color="#ffffff"><big>Home</big></font></a></td>
|
||||
<td><a href="../libs/libraries.htm"><font face="Arial" color="#ffffff"><big>
|
||||
Libraries</big></font></a></td>
|
||||
<td><a href="../people/people.htm"><font face="Arial" color="#ffffff"><big>
|
||||
People</big></font></a></td>
|
||||
<td><a href="faq.htm"><font face="Arial" color="#ffffff"><big>FAQ</big></font></a></td>
|
||||
<td><a href="index.htm"><font face="Arial" color="#ffffff"><big>More</big></font></a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h1>What to do about Boost bugs</h1>
|
||||
|
||||
<ol>
|
||||
|
||||
<li>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 <a href="http://www.boost.org/more/getting_started.html#CVS">boost public
|
||||
CVS repository</a>.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>If you are a Boost user, or a Boost developer that doesn't have a CVS
|
||||
write access: <br>
|
||||
<br>
|
||||
<ol>
|
||||
<li>Submit a bug report to either
|
||||
<a href="http://www.boost.org/more/mailing_lists.htm#users">boost-users list</a>,
|
||||
<a href="http://www.boost.org/more/mailing_lists.htm#main">boost mailing
|
||||
list</a>, or our <a href="http://svn.boost.org/trac/boost/report">bug
|
||||
tracking facility</a>; submitting it to either of the mailing
|
||||
lists is a preferred way - because many of the Boost developers read the
|
||||
lists on a daily basis, this way you are likely to get a quicker response,
|
||||
and the discussions that often arise there from (possible) bug reports are
|
||||
quite interesting and educational as well;<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>If you have a proposed patch to the code, post it along with your bug
|
||||
report, preferably in the <em>unified diffs</em> format (<code>cvs diff -du</code>);
|
||||
if you can, send a patch relative to the current CVS state. A canonical
|
||||
example of creating a patch file follows (let's assume that you've found
|
||||
a bug in the file <code>intentional_bug.hpp</code>:<br>
|
||||
<br>
|
||||
<ol>
|
||||
<li>Download the latest version of <code>intentional_bug.hpp</code> from CVS.</li>
|
||||
<li>Make sure that the bug is still present in the code.</li>
|
||||
<li>Copy the file <code>intentional_bug.hpp</code> to a file called <code>intentional_bug.hpp.orig</code>.</li>
|
||||
<li>Apply your changes to <code>intentional_bug.hpp</code>.</li>
|
||||
<li>Run "<code>diff -du intentional_bug.hpp.orig intentional_bug.hpp > intentional_bug.hpp.patch</code>" from the command prompt.</li>
|
||||
<li>Submit the patch file together with an explanation of the bug
|
||||
and the proposed fix; and don't forget to include the word <b>patch</b> or <b>bug</b>
|
||||
in the subject if you're submitting to the <a href="http://www.boost.org/more/mailing_lists.htm#main">boost mailing list</a>.<br>
|
||||
<br>
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
</li>
|
||||
|
||||
</ol>
|
||||
</li>
|
||||
<li>If you are a Boost developer, and you have a CVS write access: <br>
|
||||
<br>
|
||||
<ol>
|
||||
<li>If the bug is trivial (e.g. misspelled name, missed <code>typename</code>,
|
||||
etc.), and you are willing to make a fix, either make your changes locally
|
||||
and contact the library author(s)/maintainer(s) about it, or go ahead and
|
||||
check the fix into CVS, but post a notification about it to the
|
||||
<a href="http://www.boost.org/more/mailing_lists.htm#main">boost mailing
|
||||
list</a> (if the author is not very active on the list, you also might want
|
||||
to consider <code>cc</code>'ing him as well); <br>
|
||||
<br>
|
||||
</li>
|
||||
<li>If the bug is non-trivial, and/or you don't have the time and resources to fix it,
|
||||
submit a bug report (see p. 2 above); chances are that the maintainer(s)
|
||||
will respond promptly and take care of the problem; <br>
|
||||
<br>
|
||||
</li>
|
||||
<li>Otherwise, create a temporary branch in CVS, make your changes there, and
|
||||
ask the library author(s)/maintainer(s) to review them; if they are ok with
|
||||
the new code, either you or they can integrate the fixes into the main
|
||||
trunk. </li>
|
||||
</ol>
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<hr>
|
||||
<p>Revised <!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan -->18 January, 2002<!--webbot bot="Timestamp" i-checksum="38453" endspan -->
|
||||
</p>
|
||||
|
||||
<p>© Copyright <a href="../people/aleksey_gurtovoy.htm">Aleksey Gurtovoy</a>
|
||||
2002</p>
|
||||
<p> Distributed under the Boost Software License, Version 1.0.
|
||||
(See accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or
|
||||
copy at <a href="http://www.boost.org/LICENSE_1_0.txt">www.boost.org/LICENSE_1_0.txt</a>)
|
||||
</p>
|
||||
|
||||
<br>
|
||||
|
||||
</body></html>
|
||||
|
774
count_bdy.htm
774
count_bdy.htm
@ -1,774 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Language" content="en-us">
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
|
||||
<meta name="GENERATOR" content="Microsoft FrontPage 6.0">
|
||||
<meta name="Author" content="Kevlin Henney">
|
||||
<meta name="KeyWords" content=
|
||||
"C++, Reference Counting, Advanced Techniques, Smart Pointers, Patterns">
|
||||
|
||||
<title>Counted Body Techniques</title>
|
||||
</head>
|
||||
|
||||
<body bgcolor="#FFFFFF" text="#000000">
|
||||
<h1 align="center"><i><font size="+4">Counted Body Techniques</font></i></h1>
|
||||
|
||||
<center>
|
||||
<p><b><font size="+1"><a href="../people/kevlin_henney.htm">Kevlin Henney</a><br></font>
|
||||
(<a href=
|
||||
"mailto:kevlin@acm.org">kevlin@acm.org</a>, <a href=
|
||||
"mailto:khenney@qatraining.com">khenney@qatraining.com</a>)</b></p>
|
||||
</center>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<p>Reference counting techniques? Nothing new, you might think. Every good
|
||||
C++ text that takes you to an intermediate or advanced level will
|
||||
introduce the concept. It has been explored with such thoroughness in the
|
||||
past that you might be forgiven for thinking that everything that can be
|
||||
said has been said. Well, let's start from first principles and see if we
|
||||
can unearth something new....</p>
|
||||
</div>
|
||||
<hr width="100%">
|
||||
|
||||
<h2>And then there were none...</h2>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<p>The principle behind reference counting is to keep a running usage
|
||||
count of an object so that when it falls to zero we know the object is
|
||||
unused. This is normally used to simplify the memory management for
|
||||
dynamically allocated objects: keep a count of the number of references
|
||||
held to that object and, on zero, delete the object.</p>
|
||||
|
||||
<p>How to keep a track of the number of users of an object? Well, normal
|
||||
pointers are quite dumb, and so an extra level of indirection is required
|
||||
to manage the count. This is essentially the P<font size="-1">ROXY</font>
|
||||
pattern described in <i>Design Patterns</i> [Gamma, Helm, Johnson &
|
||||
Vlissides, Addison-Wesley, <font size="-1">ISBN</font> 0-201-63361-2]. The
|
||||
intent is given as</p>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<p><i>Provide a surrogate or placeholder for another object to control
|
||||
access to it.</i></p>
|
||||
</div>
|
||||
|
||||
<p>Coplien [<i>Advanced C++ Programming Styles and Idioms</i>,
|
||||
Addison-Wesley, <font size="-1">ISBN</font> 0-201-56365-7] defines a set
|
||||
of idioms related to this essential separation of a handle and a body
|
||||
part. The <i>Taligent Guide to Designing Programs</i> [Addison-Wesley,
|
||||
<font size="-1">ISBN</font> 0-201-40888-0] identifies a number of specific
|
||||
categories for proxies (aka surrogates). Broadly speaking they fall into
|
||||
two general categories:</p>
|
||||
|
||||
<ul>
|
||||
<li><i>Hidden</i>: The handle is the object of interest, hiding the body
|
||||
itself. The functionality of the handle is obtained by delegation to the
|
||||
body, and the user of the handle is unaware of the body. Reference
|
||||
counted strings offer a transparent optimisation. The body is shared
|
||||
between copies of a string until such a time as a change is needed, at
|
||||
which point a copy is made. Such a C<font size=
|
||||
"-1">OPY</font> <font size="-1">ON</font> W<font size="-1">RITE</font>
|
||||
pattern (a specialisation of L<font size="-1">AZY</font> E<font size=
|
||||
"-1">VALUATION</font>) requires the use of a hidden reference counted
|
||||
body.</li>
|
||||
|
||||
<li><i>Explicit</i>: Here the body is of interest and the handle merely
|
||||
provides intelligence for its access and housekeeping. In C++ this is
|
||||
often implemented as the S<font size="-1">MART</font> P<font size=
|
||||
"-1">OINTER</font> idiom. One such application is that of reference
|
||||
counted smart pointers that collaborate to keep a count of an object,
|
||||
deleting it when the count falls to zero.</li>
|
||||
</ul>
|
||||
</div>
|
||||
<hr width="100%">
|
||||
|
||||
<h2>Attached vs detached</h2>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<p>For reference counted smart pointers there are two places the count can
|
||||
exist, resulting in two different patterns, both outlined in
|
||||
<i>Software Patterns</i> [Coplien, SIGS, <font size="-1">ISBN</font>
|
||||
0-884842-50-X]:</p>
|
||||
|
||||
<ul>
|
||||
<li>C<font size="-1">OUNTED</font> B<font size="-1">ODY</font> or A<font size="-1">TTACHED</font>
|
||||
C<font size="-1">OUNTED</font>
|
||||
H<font size="-1">ANDLE</font>/B<font size="-1">ODY</font> places the
|
||||
count within the object being counted. The benefits are that
|
||||
countability is a part of the object being counted, and that reference
|
||||
counting does not require an additional object. The drawbacks are
|
||||
clearly that this is intrusive, and that the space for the reference
|
||||
count is wasted when the object is not heap based. Therefore the
|
||||
reference counting ties you to a particular implementation and style of
|
||||
use.</li>
|
||||
|
||||
<li>D<font size="-1">ETACHED</font> C<font size="-1">OUNTED</font>
|
||||
H<font size="-1">ANDLE</font>/B<font size="-1">ODY</font> places the
|
||||
count outside the object being counted, such that they are handled
|
||||
together. The clear benefit of this is that this technique is completely
|
||||
unintrusive, with all of the intelligence and support apparatus in the
|
||||
smart pointer, and therefore can be used on classes created
|
||||
independently of the reference counted pointer. The main disadvantage is
|
||||
that frequent use of this can lead to a proliferation of small objects,
|
||||
i.e. the counter, being created on the heap.</li>
|
||||
</ul>
|
||||
|
||||
<p>Even with this simple analysis, it seems that the D<font size=
|
||||
"-1">ETACHED</font> C<font size="-1">OUNTED</font> H<font size=
|
||||
"-1">ANDLE</font>/B<font size="-1">ODY</font> approach is ahead. Indeed,
|
||||
with the increasing use of templates this is often the favourite, and is
|
||||
the principle behind the common - but not standard - <tt><font size=
|
||||
"+1">counted_ptr</font></tt>. <i>[The Boost name is <a href=
|
||||
"../libs/smart_ptr/shared_ptr.htm"><tt><font size=
|
||||
"+1">shared_ptr</font></tt></a> rather than <tt><font size=
|
||||
"+1">counted_ptr</font></tt>.]</i></p>
|
||||
|
||||
<p>A common implementation of C<font size="-1">OUNTED</font> B<font size=
|
||||
"-1">ODY</font> is to provide the counting mechanism in a base class that
|
||||
the counted type is derived from. Either that, or the reference counting
|
||||
mechanism is provided anew for each class that needs it. Both of these
|
||||
approaches are unsatisfactory because they are quite closed, coupling a
|
||||
class into a particular framework. Added to this the non-cohesiveness of
|
||||
having the count lying dormant in a non-counted object, and you get the
|
||||
feeling that excepting its use in widespread object models such as COM and
|
||||
CORBA the C<font size="-1">OUNTED</font> B<font size="-1">ODY</font>
|
||||
approach is perhaps only of use in specialised situations.</p>
|
||||
</div>
|
||||
<hr width="100%">
|
||||
|
||||
<h2>A requirements based approach</h2>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<p>It is the question of openness that convinced me to revisit the
|
||||
problems with the C<font size="-1">OUNTED</font> B<font size=
|
||||
"-1">ODY</font> idiom. Yes, there is a certain degree of intrusion
|
||||
expected when using this idiom, but is there anyway to minimise this and
|
||||
decouple the choice of counting mechanism from the smart pointer type
|
||||
used?</p>
|
||||
|
||||
<p>In recent years the most instructive body of code and specification for
|
||||
constructing open general purpose components has been the Stepanov and
|
||||
Lee's STL (Standard Template Library), now part of the C++ standard
|
||||
library. The STL approach makes extensive use of compile time polymorphism
|
||||
based on well defined operational requirements for types. For instance,
|
||||
each container, contained and iterator type is defined by the operations
|
||||
that should be performable on an object of that type, often with
|
||||
annotations describing additional constraints. Compile time polymorphism,
|
||||
as its name suggests, resolves functions at compile time based on function
|
||||
name and argument usage, i.e. overloading. This is less intrusive,
|
||||
although less easily diagnosed if incorrect, than runtime poymorphism that
|
||||
is based on types, names and function signatures.</p>
|
||||
|
||||
<p>This requirements based approach can be applied to reference counting.
|
||||
The operations we need for a type to be <i>Countable</i> are loosely:</p>
|
||||
|
||||
<ul>
|
||||
<li>An <tt><font size="+1">acquire</font></tt> operation that registers
|
||||
interest in a <i>Countable</i> object.</li>
|
||||
|
||||
<li>A <tt><font size="+1">release</font></tt> operation unregisters
|
||||
interest in a <i>Countable</i> object.</li>
|
||||
|
||||
<li>An <tt><font size="+1">acquired</font></tt> query that returns
|
||||
whether or not a <i>Countable</i> object is currently acquired.</li>
|
||||
|
||||
<li>A <tt><font size="+1">dispose</font></tt> operation that is
|
||||
responsible for disposing of an object that is no longer acquired.</li>
|
||||
</ul>
|
||||
|
||||
<p>Note that the count is deduced as a part of the abstract state of this
|
||||
type, and is not mentioned or defined in any other way. The openness of
|
||||
this approach derives in part from the use of global functions, meaning
|
||||
that no particular member functions are implied; a perfect way to wrap up
|
||||
an existing counted body class without modifying the class itself. The
|
||||
other aspect to the openness comes from a more precise specification of
|
||||
the operations.</p>
|
||||
|
||||
<p>For a type to be <i>Countable</i> it must satisfy the following
|
||||
requirements, where <tt><font size="+1">ptr</font></tt> is a non-null
|
||||
pointer to a single object (i.e. not an array) of the type, and
|
||||
<i><tt><font size="+1">#function</font></tt></i> indicates number of calls
|
||||
to <tt><font size="+1"><i>function(</i>ptr<i>)</i></font></tt>:</p>
|
||||
|
||||
<center>
|
||||
<table border="1" cellspacing="2" cellpadding="2" summary="">
|
||||
<tr>
|
||||
<td><i>Expression</i></td>
|
||||
|
||||
<td><i>Return type</i></td>
|
||||
|
||||
<td><i>Semantics and notes</i></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><tt><font size="+1">acquire(ptr)</font></tt></td>
|
||||
|
||||
<td>no requirement</td>
|
||||
|
||||
<td><i>post</i>: <tt><font size="+1">acquired(ptr)</font></tt></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><tt><font size="+1">release(ptr)</font></tt></td>
|
||||
|
||||
<td>no requirement</td>
|
||||
|
||||
<td><i>pre</i>: <tt><font size="+1">acquired(ptr)<br></font></tt>
|
||||
<i>post</i>: <tt><font size="+1">acquired(ptr) == #acquire -
|
||||
#release</font></tt></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><tt><font size="+1">acquired(ptr)</font></tt></td>
|
||||
|
||||
<td>convertible to <tt><font size="+1">bool</font></tt></td>
|
||||
|
||||
<td><i>return</i>: <tt><font size="+1">#acquire > #release</font></tt></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><tt><font size="+1">dispose(ptr, ptr)</font></tt></td>
|
||||
|
||||
<td>no requirement</td>
|
||||
|
||||
<td><i>pre</i>: <tt><font size="+1">!acquired(ptr)<br></font></tt>
|
||||
<i>post</i>: <tt><font size="+1">*ptr</font></tt> no longer usable</td>
|
||||
</tr>
|
||||
</table>
|
||||
</center>
|
||||
|
||||
<p>Note that the two arguments to <tt><font size="+1">dispose</font></tt>
|
||||
are to support selection of the appropriate type safe version of the
|
||||
function to be called. In the general case the intent is that the first
|
||||
argument determines the type to be deleted, and would typically be
|
||||
templated, while the second selects which template to use, e.g. by
|
||||
conforming to a specific base class.</p>
|
||||
|
||||
<p>In addition the following requirements must also be satisfied, where
|
||||
<tt><font size="+1">null</font></tt> is a null pointer to the
|
||||
<i>Countable</i> type:</p>
|
||||
|
||||
<center>
|
||||
<table border="1" summary="">
|
||||
<tr>
|
||||
<td><i>Expression</i></td>
|
||||
|
||||
<td><i>Return type</i></td>
|
||||
|
||||
<td><i>Semantics and notes</i></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><tt><font size="+1">acquire(null)</font></tt></td>
|
||||
|
||||
<td>no requirement</td>
|
||||
|
||||
<td><i>action</i>: none</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><tt><font size="+1">release(null)</font></tt></td>
|
||||
|
||||
<td>no requirement</td>
|
||||
|
||||
<td><i>action</i>: none</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><tt><font size="+1">acquired(null)</font></tt></td>
|
||||
|
||||
<td>convertible to <tt><font size="+1">bool</font></tt></td>
|
||||
|
||||
<td><i>return</i>: <tt><font size="+1">false</font></tt></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><tt><font size="+1">dispose(null, null)</font></tt></td>
|
||||
|
||||
<td>no requirement</td>
|
||||
|
||||
<td><i>action</i>: none</td>
|
||||
</tr>
|
||||
</table>
|
||||
</center>
|
||||
|
||||
<p>Note that there are no requirements on these functions in terms of
|
||||
exceptions thrown or not thrown, except that if exceptions are thrown the
|
||||
functions themselves should be exception safe.</p>
|
||||
</div>
|
||||
<hr width="100%">
|
||||
|
||||
<h2>Getting smart</h2>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<p>Given the <i>Countable</i> requirements for a type, it is possible to
|
||||
define a generic smart pointer type that uses them for reference counting:</p>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<pre>
|
||||
<tt>template<typename countable_type>
|
||||
class countable_ptr
|
||||
{
|
||||
public: // construction and destruction
|
||||
|
||||
explicit countable_ptr(countable_type *);
|
||||
countable_ptr(const countable_ptr &);
|
||||
~countable_ptr();
|
||||
|
||||
public: // access
|
||||
|
||||
countable_type *operator->() const;
|
||||
countable_type &operator*() const;
|
||||
countable_type *get() const;
|
||||
|
||||
public: // modification
|
||||
|
||||
countable_ptr &clear();
|
||||
countable_ptr &assign(countable_type *);
|
||||
countable_ptr &assign(const countable_ptr &);
|
||||
countable_ptr &operator=(const countable_ptr &);
|
||||
|
||||
private: // representation
|
||||
|
||||
countable_type *body;
|
||||
|
||||
};
|
||||
</tt>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>The interface to this class has been kept intentionally simple, e.g.
|
||||
member templates and <tt><font size="+1">throw</font></tt> specs have been
|
||||
omitted, for exposition. The majority of the functions are quite simple in
|
||||
implementation, relying very much on the <tt><font size=
|
||||
"+1">assign</font></tt> member as a keystone function:</p>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<pre>
|
||||
<tt>template<typename countable_type>
|
||||
countable_ptr<countable_type>::countable_ptr(countable_type *initial)
|
||||
: body(initial)
|
||||
{
|
||||
acquire(body);
|
||||
}
|
||||
|
||||
template<typename countable_type>
|
||||
countable_ptr<countable_type>::countable_ptr(const countable_ptr &other)
|
||||
: body(other.body)
|
||||
{
|
||||
acquire(body);
|
||||
}
|
||||
|
||||
template<typename countable_type>
|
||||
countable_ptr<countable_type>::~countable_ptr()
|
||||
{
|
||||
clear();
|
||||
}
|
||||
|
||||
template<typename countable_type>
|
||||
countable_type *countable_ptr<countable_type>::operator->() const
|
||||
{
|
||||
return body;
|
||||
}
|
||||
|
||||
template<typename countable_type>
|
||||
countable_type &countable_ptr<countable_type>::operator*() const
|
||||
{
|
||||
return *body;
|
||||
}
|
||||
|
||||
template<typename countable_type>
|
||||
countable_type *countable_ptr<countable_type>::get() const
|
||||
{
|
||||
return body;
|
||||
}
|
||||
|
||||
template<typename countable_type>
|
||||
countable_ptr<countable_type> &countable_ptr<countable_type>::clear()
|
||||
{
|
||||
return assign(0);
|
||||
}
|
||||
|
||||
template<typename countable_type>
|
||||
countable_ptr<countable_type> &countable_ptr<countable_type>::assign(countable_type *rhs)
|
||||
{
|
||||
// set to rhs (uses Copy Before Release idiom which is self assignment safe)
|
||||
acquire(rhs);
|
||||
countable_type *old_body = body;
|
||||
body = rhs;
|
||||
|
||||
// tidy up
|
||||
release(old_body);
|
||||
if(!acquired(old_body))
|
||||
{
|
||||
dispose(old_body, old_body);
|
||||
}
|
||||
|
||||
return *this;
|
||||
}
|
||||
|
||||
template<typename countable_type>
|
||||
countable_ptr<countable_type> &countable_ptr<countable_type>::assign(const countable_ptr &rhs)
|
||||
{
|
||||
return assign(rhs.body);
|
||||
}
|
||||
|
||||
template<typename countable_type>
|
||||
countable_ptr<countable_type> &countable_ptr<countable_type>::operator=(const countable_ptr &rhs)
|
||||
{
|
||||
return assign(rhs);
|
||||
}
|
||||
</tt>
|
||||
</pre>
|
||||
</div>
|
||||
</div>
|
||||
<hr width="100%">
|
||||
|
||||
<h2>Public accountability</h2>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<p>Conformance to the requirements means that a type can be used with
|
||||
<tt><font size="+1">countable_ptr</font></tt>. Here is an implementation
|
||||
mix-in class (<i>mix-imp</i>) that confers countability on its derived
|
||||
classes through member functions. This class can be used as a class
|
||||
adaptor:</p>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<pre>
|
||||
<tt>class countability
|
||||
{
|
||||
public: // manipulation
|
||||
|
||||
void acquire() const;
|
||||
void release() const;
|
||||
size_t acquired() const;
|
||||
|
||||
protected: // construction and destruction
|
||||
|
||||
countability();
|
||||
~countability();
|
||||
|
||||
private: // representation
|
||||
|
||||
mutable size_t count;
|
||||
|
||||
private: // prevention
|
||||
|
||||
countability(const countability &);
|
||||
countability &operator=(const countability &);
|
||||
|
||||
};
|
||||
</tt>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>Notice that the manipulation functions are <tt><font size=
|
||||
"+1">const</font></tt> and that the <tt><font size="+1">count</font></tt>
|
||||
member itself is <tt><font size="+1">mutable</font></tt>. This is because
|
||||
countability is not a part of an object's abstract state: memory
|
||||
management does not depend on the <tt><font size=
|
||||
"+1">const</font></tt>-ness or otherwise of an object. I won't include the
|
||||
definitions of the member functions here as you can probably guess them:
|
||||
increment, decrement and return the current count, respectively for the
|
||||
manipulation functions. In a multithreaded environment you should ensure
|
||||
that such read and write operations are atomic.</p>
|
||||
|
||||
<p>So how do we make this class <i>Countable</i>? A simple set of
|
||||
forwarding functions does the job:</p>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<pre>
|
||||
<tt>void acquire(const countability *ptr)
|
||||
{
|
||||
if(ptr)
|
||||
{
|
||||
ptr->acquire();
|
||||
}
|
||||
}
|
||||
|
||||
void release(const countability *ptr)
|
||||
{
|
||||
if(ptr)
|
||||
{
|
||||
ptr->release();
|
||||
}
|
||||
}
|
||||
|
||||
size_t acquired(const countability *ptr)
|
||||
{
|
||||
return ptr ? ptr->acquired() : 0;
|
||||
}
|
||||
|
||||
template<class countability_derived>
|
||||
void dispose(const countability_derived *ptr, const countability *)
|
||||
{
|
||||
delete ptr;
|
||||
}
|
||||
</tt>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>Any type that now derives from <tt><font size=
|
||||
"+1">countability</font></tt> may now be used with <tt><font size=
|
||||
"+1">countable_ptr</font></tt>:</p>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<pre>
|
||||
<tt>class example : public countability
|
||||
{
|
||||
...
|
||||
};
|
||||
|
||||
void simple()
|
||||
{
|
||||
countable_ptr<example> ptr(new example);
|
||||
countable_ptr<example> qtr(ptr);
|
||||
ptr.clear(); // set ptr to point to null
|
||||
} // allocated object deleted when qtr destructs
|
||||
</tt>
|
||||
</pre>
|
||||
</div>
|
||||
</div>
|
||||
<hr width="100%">
|
||||
|
||||
<h2>Runtime mixin</h2>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<p>The challenge is to apply C<font size="-1">OUNTED</font> B<font size=
|
||||
"-1">ODY</font> in a non-intrusive fashion, such that there is no overhead
|
||||
when an object is not counted. What we would like to do is confer this
|
||||
capability on a per object rather than on a per class basis. Effectively
|
||||
we are after <i>Countability</i> on any object, i.e. anything pointed to
|
||||
by a <tt><font size="+1">void *</font></tt>! It goes without saying that <tt><font size="+1">
|
||||
void</font></tt> is perhaps the least committed of any type.</p>
|
||||
|
||||
<p>The forces to resolve on this are quite interesting, to say the least.
|
||||
Interesting, but not insurmountable. Given that the class of a runtime
|
||||
object cannot change dynamically in any well defined manner, and the
|
||||
layout of the object must be fixed, we have to find a new place and time
|
||||
to add the counting state. The fact that this must be added only on heap
|
||||
creation suggests the following solution:</p>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<pre>
|
||||
<tt>struct countable_new;
|
||||
extern const countable_new countable;
|
||||
|
||||
void *operator new(size_t, const countable_new &);
|
||||
void operator delete(void *, const countable_new &);</tt>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>We have overloaded <tt><font size="+1">operator new</font></tt> with a
|
||||
dummy argument to distinguish it from the regular global <tt><font size=
|
||||
"+1">operator new</font></tt>. This is comparable to the use of the
|
||||
<tt><font size="+1">std::nothrow_t</font></tt> type and <tt><font size=
|
||||
"+1">std::nothrow</font></tt> object in the standard library. The
|
||||
placement <tt><font size="+1">operator delete</font></tt> is there to
|
||||
perform any tidy up in the event of failed construction. Note that this is
|
||||
not yet supported on all that many compilers.</p>
|
||||
|
||||
<p>The result of a <tt><font size="+1">new</font></tt> expression using
|
||||
<tt><font size="+1">countable</font></tt> is an object allocated on the
|
||||
heap that has a header block that holds the count, i.e. we have extended
|
||||
the object by prefixing it. We can provide a couple of features in an
|
||||
anonymous namespace (not shown) in the implementation file for for
|
||||
supporting the count and its access from a raw pointer:</p>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<pre>
|
||||
<tt>struct count
|
||||
{
|
||||
size_t value;
|
||||
};
|
||||
|
||||
count *header(const void *ptr)
|
||||
{
|
||||
return const_cast<count *>(static_cast<const count *>(ptr) - 1);
|
||||
}
|
||||
</tt>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>An important constraint to observe here is the alignment of
|
||||
<tt><font size="+1">count</font></tt> should be such that it is suitably
|
||||
aligned for any type. For the definition shown this will be the case on
|
||||
almost all platforms. However, you may need to add a padding member for
|
||||
those that don't, e.g. using an anonymous <tt><font size=
|
||||
"+1">union</font></tt> to coalign <tt><font size="+1">count</font></tt>
|
||||
and the most aligned type. Unfortunately, there is no portable way of
|
||||
specifying this such that the minimum alignment is also observed - this is
|
||||
a common problem when specifying your own allocators that do not directly
|
||||
use the results of either <tt><font size="+1">new</font></tt> or
|
||||
<tt><font size="+1">malloc</font></tt>.</p>
|
||||
|
||||
<p>Again, note that the count is not considered to be a part of the
|
||||
logical state of the object, and hence the conversion from
|
||||
<tt><font size="+1">const</font></tt> to non-<tt><font size=
|
||||
"+1">const</font></tt> - <tt><font size="+1">count</font></tt> is in
|
||||
effect a <tt><font size="+1">mutable</font></tt> type.</p>
|
||||
|
||||
<p>The allocator functions themselves are fairly straightforward:</p>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<pre>
|
||||
<tt>void *operator new(size_t size, const countable_new &)
|
||||
{
|
||||
count *allocated = static_cast<count *>(::operator new(sizeof(count) + size));
|
||||
*allocated = count(); // initialise the header
|
||||
return allocated + 1; // adjust result to point to the body
|
||||
}
|
||||
|
||||
void operator delete(void *ptr, const countable_new &)
|
||||
{
|
||||
::operator delete(header(ptr));
|
||||
}
|
||||
</tt>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>Given a correctly allocated header, we now need the <i>Countable</i>
|
||||
functions to operate on <tt><font size="+1">const void *</font></tt> to
|
||||
complete the picture:</p>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<pre>
|
||||
<tt>void acquire(const void *ptr)
|
||||
{
|
||||
if(ptr)
|
||||
{
|
||||
++header(ptr)->value;
|
||||
}
|
||||
}
|
||||
|
||||
void release(const void *ptr)
|
||||
{
|
||||
if(ptr)
|
||||
{
|
||||
--header(ptr)->value;
|
||||
}
|
||||
}
|
||||
|
||||
size_t acquired(const void *ptr)
|
||||
{
|
||||
return ptr ? header(ptr)->value : 0;
|
||||
}
|
||||
|
||||
template<typename countable_type>
|
||||
void dispose(const countable_type *ptr, const void *)
|
||||
{
|
||||
ptr->~countable_type();
|
||||
operator delete(const_cast<countable_type *>(ptr), countable);
|
||||
}
|
||||
</tt>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>The most complex of these is the <tt><font size=
|
||||
"+1">dispose</font></tt> function that must ensure that the correct type
|
||||
is destructed and also that the memory is collected from the correct
|
||||
offset. It uses the value and type of first argument to perform this
|
||||
correctly, and the second argument merely acts as a strategy selector,
|
||||
i.e. the use of <tt><font size="+1">const void *</font></tt>
|
||||
distinguishes it from the earlier dispose shown for <tt><font size=
|
||||
"+1">const countability *</font></tt>.</p>
|
||||
</div>
|
||||
<hr width="100%">
|
||||
|
||||
<h2>Getting smarter</h2>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<p>Now that we have a way of adding countability at creation for objects
|
||||
of any type, what extra is needed to make this work with the
|
||||
<tt><font size="+1">countable_ptr</font></tt> we defined earlier? Good
|
||||
news: nothing!</p>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<pre>
|
||||
<tt>class example
|
||||
{
|
||||
...
|
||||
};
|
||||
|
||||
void simple()
|
||||
{
|
||||
countable_ptr<example> ptr(new(countable) example);
|
||||
countable_ptr<example> qtr(ptr);
|
||||
ptr.clear(); // set ptr to point to null
|
||||
} // allocated object deleted when qtr destructs
|
||||
</tt>
|
||||
</pre>
|
||||
</div>
|
||||
|
||||
<p>The <tt><font size="+1">new(countable)</font></tt> expression defines a
|
||||
different policy for allocation and deallocation and, in common with other
|
||||
allocators, any attempt to mix your allocation policies, e.g. call
|
||||
<tt><font size="+1">delete</font></tt> on an object allocated with
|
||||
<tt><font size="+1">new(countable)</font></tt>, results in undefined
|
||||
behaviour. This is similar to what happens when you mix <tt><font size=
|
||||
"+1">new[]</font></tt> with <tt><font size="+1">delete</font></tt> or
|
||||
<tt><font size="+1">malloc</font></tt> with <tt><font size=
|
||||
"+1">delete</font></tt>. The whole point of <i>Countable</i> conformance
|
||||
is that <i>Countable</i> objects are used with <tt><font size=
|
||||
"+1">countable_ptr</font></tt>, and this ensures the correct use.</p>
|
||||
|
||||
<p>However, accidents will happen, and inevitably you may forget to
|
||||
allocate using <tt><font size="+1">new(countable)</font></tt> and instead
|
||||
use <tt><font size="+1">new</font></tt>. This error and others can be
|
||||
detected in most cases by extending the code shown here to add a check
|
||||
member to the <tt><font size="+1">count</font></tt>, validating the check
|
||||
on every access. A benefit of ensuring clear separation between header and
|
||||
implementation source files means that you can introduce a checking
|
||||
version of this allocator without having to recompile your code.</p>
|
||||
</div>
|
||||
<hr width="100%">
|
||||
|
||||
<h2>Conclusion</h2>
|
||||
|
||||
<div style="margin-left: 2em">
|
||||
<p>There are two key concepts that this article has introduced:</p>
|
||||
|
||||
<ul>
|
||||
<li>The use of a generic requirements based approach to simplify and
|
||||
adapt the use of the C<font size="-1">OUNTED</font> B<font size=
|
||||
"-1">ODY</font> pattern.</li>
|
||||
|
||||
<li>The ability, through control of allocation, to dynamically and
|
||||
non-intrusively add capabilities to fixed types using the R<font size=
|
||||
"-1">UNTIME</font> M<font size="-1">IXIN</font> pattern.</li>
|
||||
</ul>
|
||||
|
||||
<p>The application of the two together gives rise to a new variant of the
|
||||
essential C<font size="-1">OUNTED</font> B<font size="-1">ODY</font>
|
||||
pattern, U<font size="-1">NINTRUSIVE</font> C<font size=
|
||||
"-1">OUNTED</font> B<font size="-1">ODY</font>. You can take this theme
|
||||
even further and contrive a simple garbage collection system for C++.</p>
|
||||
|
||||
<p>The complete code for <tt><font size="+1">countable_ptr</font></tt>,
|
||||
<tt><font size="+1">countability</font></tt>, and the <tt><font size=
|
||||
"+1">countable new</font></tt> is also available.</p>
|
||||
</div>
|
||||
|
||||
<div align="right">
|
||||
<hr width="100%">
|
||||
<font size="-1"><i>First published in</i> <a href=
|
||||
"http://www.accu.org/c++sig/public/Overload.html">Overload</a> <i>25,
|
||||
April 1998, ISSN 1354-3172</i></font>
|
||||
</div>
|
||||
|
||||
<p><a href="http://validator.w3.org/check?uri=referer"><img border="0" src=
|
||||
"http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01 Transitional"
|
||||
height="31" width="88"></a></p>
|
||||
|
||||
<p>Revised
|
||||
<!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan -->04 December, 2006<!--webbot bot="Timestamp" endspan i-checksum="38514" --></p>
|
||||
|
||||
<p><i>Copyright © 1998-1999 Kevlin Henney</i></p>
|
||||
|
||||
<p><i>Distributed under the Boost Software License, Version 1.0. (See
|
||||
accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy
|
||||
at <a href=
|
||||
"http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>)</i></p>
|
||||
</body>
|
||||
</html>
|
@ -1,125 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<meta http-equiv="Content-Language" content="en-us">
|
||||
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
||||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
||||
<title>C++ Committee Meetings</title>
|
||||
</head>
|
||||
|
||||
<body bgcolor="#FFFFFF">
|
||||
|
||||
<h1>C++ Committee Meeting FAQ for Boost Members</h1>
|
||||
<p><b>Who can attend C++ Committee meetings?</b> Members of
|
||||
J16 (the INCITS/ANSI committee) or of a WG21 (ISO) member country committee
|
||||
("national body" in
|
||||
ISO-speak). <a href="http://www.ncits.org/">
|
||||
INCITS</a> has broadened J16 membership requirements so anyone can
|
||||
join, regardless of nationality or employer.</p>
|
||||
<p>In addition, a small number of "technical experts" who are not committee
|
||||
members can also attend meetings. The "technical expert" umbrella is broad enough to cover
|
||||
the
|
||||
Boost members who attend meetings.</p>
|
||||
<p><b>When and where is the next meeting?</b> There are two meetings a year. The
|
||||
Fall meeting is usually in North America, and the Spring meeting is usually
|
||||
outside North America. See a general
|
||||
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/meetings">list of meeting locations and
|
||||
dates</a>. Detailed information about a particular meeting, including hotel
|
||||
information, is usually provided in a paper appearing in one of
|
||||
<a href="#Mailing">mailings</a> for the prior meeting. If there isn't a link to
|
||||
it on the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/meetings">
|
||||
Meetings</a> web page, you will have to go to
|
||||
the committee's <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/">
|
||||
Papers</a> page and search a bit.</p>
|
||||
<p><b>Is there a fee for attending meetings?</b> No, but there can be a lot of
|
||||
incidental expenses like travel, lodging, and meals, and there is a $US 800 a
|
||||
year INCITS fee to become a voting member.</p>
|
||||
<p><b>What is the schedule?</b> The meetings start at 9:00AM on
|
||||
Monday, and 8:30AM other days, unless otherwise announced. It is best to arrive
|
||||
a half-hour early to grab a good seat, some coffee, tea, or donuts, and to say
|
||||
hello to people. (There is also a Sunday evening a WG21 administrative meeting,
|
||||
which is closed except to delegates from national bodies.)</p>
|
||||
<p>The meetings generally end on Friday, although there is discussion of
|
||||
extending them one extra day until the next standard ships. The last day the meeting is generally over by 11:00AM. Because
|
||||
the last day's meeting is for formal votes only, it is primarily of interest only to
|
||||
actual committee
|
||||
members.</p>
|
||||
<p>Sometimes there are evening technical sessions; the details aren't
|
||||
usually available until the Monday morning meeting. There may be a
|
||||
reception one evening, and, yes, significant others are
|
||||
invited. Again, details usually become available Monday morning.</p>
|
||||
<p><b>What actually happens at the meetings?</b> Monday morning an hour or two
|
||||
is spent in full committee on administrivia, and then the committee breaks up
|
||||
into working groups (Core, Library, and Enhancements). The full committee also
|
||||
gets together later in the week to hear working group progress reports.</p>
|
||||
<p>The working groups are where most technical activities take place. Each
|
||||
active issue that appears on an issues list is discussed, as are papers from the
|
||||
mailing. Most issues are non-controversial and disposed of in a few minutes.
|
||||
Technical discussions are often led by long-term committee members, often
|
||||
referring to past decisions or longstanding working group practice. Sometimes a
|
||||
controversy erupts. It takes first-time attendees awhile to understand the
|
||||
discussions and how decisions are actually made. The working group chairperson
|
||||
moderates.</p>
|
||||
<p>Sometimes straw polls are taken. In a straw poll anyone attending can vote,
|
||||
in contrast to the formal votes taken by the full committee, where only voting
|
||||
members can vote.</p>
|
||||
<p>Lunch break is an hour and a half. Informal subgroups often lunch
|
||||
together; a lot of technical problems are discussed or actually solved at lunch,
|
||||
or later at dinner. In many ways these discussions involving only a few people
|
||||
are the most interesting. Sometimes during the regular meetings, a working group
|
||||
chair will break off a sub-group to tackle a difficult problem. </p>
|
||||
<p><b>Do I have to stay at the main hotel?</b> No, and committee members on
|
||||
tight budgets often stay at other, cheaper, hotels. (The main hotels are usually
|
||||
chosen because they have large meeting rooms available, and thus tend to be pricey.)
|
||||
The advantage of staying at the main hotel is that it is then easier to
|
||||
participate in the off-line discussions which can be at least as interesting
|
||||
as what actually happens in the scheduled meetings.</p>
|
||||
<p><b>What do people wear at meetings?</b> Programmer casual. No neckties
|
||||
to be seen. </p>
|
||||
<p><b>What should I bring to a meeting?</b> It is almost essential to have a
|
||||
laptop computer along. There is a committee LAN with a wiki and Internet connectivity.
|
||||
Wireless connectivity has become the norm, although there is usually a wired hub
|
||||
or two for those needed wired access.</p>
|
||||
<p><b>What should I do to prepare for a meeting?</b> It is helpful to have
|
||||
downloaded the mailing or individual papers for the
|
||||
meeting, and read any papers you are interested in. Familiarize yourself with
|
||||
the issues lists if you haven't done so already. Decide which of the working
|
||||
groups you want to attend.</p>
|
||||
<p><b>What is a "<a name="Paper">Paper</a>"?</b> An electronic document containing issues,
|
||||
proposals, or anything else the committee is interested in. Very little gets
|
||||
discussed at a meeting, much less acted upon, unless it is presented in a paper.
|
||||
<a href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/">Papers are available</a>
|
||||
to anyone. Papers don't just appear randomly; they become available four (lately
|
||||
six) times a
|
||||
year, before and after each meeting. Committee members often refer to a paper by
|
||||
saying what mailing it was in: "See the pre-Redmond mailing."</p>
|
||||
<p><b>What is a "<a name="Mailing">Mailing</a>"?</b> A mailing is the
|
||||
set of papers prepared four to six times a year before and after each meeting,
|
||||
or between meetings. It
|
||||
is physically just a
|
||||
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/mailings/">.zip or .gz</a>
|
||||
archive of
|
||||
all the papers for a meeting. Although the mailing's archive file itself is only available to committee members and technical
|
||||
experts, the contents (except copies of the standard) are available to the
|
||||
general public as individual papers. The ways of ISO are
|
||||
inscrutable.</p>
|
||||
<p><b>What is a "Reflector"?</b> The committee's mailing lists are
|
||||
called "reflectors". There are a number of them; "all", "core", "lib", and "ext"
|
||||
are the main ones. As a courtesy, Boost technical experts can be added to
|
||||
committee reflectors at the request of a committee member. </p>
|
||||
<hr>
|
||||
<p>Revised
|
||||
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%B %d, %Y" startspan -->April 17, 2005<!--webbot bot="Timestamp" endspan i-checksum="17669" --></p>
|
||||
<p>© Copyright Beman Dawes, 2002</p>
|
||||
<p>
|
||||
Distributed under the Boost Software License, Version 1.0. (See
|
||||
accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy
|
||||
at <a href=
|
||||
"http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>)
|
||||
</p>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
@ -1,370 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Language" content="en-us">
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
|
||||
|
||||
<meta name="generator" content="Microsoft FrontPage 6.0">
|
||||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||||
|
||||
<title>Boost Discussion Policy</title>
|
||||
</head>
|
||||
|
||||
<body bgcolor="#FFFFFF" text="#000000">
|
||||
<table border="1" bgcolor="#007F7F" cellpadding="2" summary="">
|
||||
<tr>
|
||||
<td bgcolor="#FFFFFF"><img src="../boost.png" alt=
|
||||
"boost.png (6897 bytes)" width="277" height="86"></td>
|
||||
|
||||
<td><a href="../index.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>Home</big></font></a></td>
|
||||
|
||||
<td><a href="../libs/libraries.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>Libraries</big></font></a></td>
|
||||
|
||||
<td><a href="../people/people.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>People</big></font></a></td>
|
||||
|
||||
<td><a href="faq.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>FAQ</big></font></a></td>
|
||||
|
||||
<td><a href="index.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>More</big></font></a></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>Boost Discussion Policy</h1>
|
||||
|
||||
<p>Email discussion is the tie that binds boost members together into a
|
||||
community. If the discussion is stimulating and effective, the community
|
||||
thrives. If the discussion degenerates into name calling and ill will, the
|
||||
community withers and dies.</p>
|
||||
|
||||
<h2>Contents</h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="#acceptable">Acceptable Topics</a></dt>
|
||||
|
||||
<dt><a href="#unacceptable">Unacceptable Topics</a></dt>
|
||||
|
||||
<dt><a href="#effective">Effective Posting</a></dt>
|
||||
|
||||
<dt><a href="#behavior">Prohibited Behavior</a></dt>
|
||||
|
||||
<dt><a href="#culture">Culture</a></dt>
|
||||
|
||||
<dt><a href="#lib_names">Library Names</a></dt>
|
||||
</dl>
|
||||
|
||||
<h2><a name="acceptable" id="acceptable"></a>Acceptable topics</h2>
|
||||
|
||||
<ul>
|
||||
<li>Queries to determine interest in a possible library submission.</li>
|
||||
|
||||
<li>Technical discussions about a proposed or existing library, including
|
||||
bug reports and requests for help.</li>
|
||||
|
||||
<li>Formal Reviews of proposed libraries.</li>
|
||||
|
||||
<li>Reports of user experiences with Boost libraries.</li>
|
||||
|
||||
<li>Boost administration or policies.</li>
|
||||
|
||||
<li>Compiler specific workarounds as applied to Boost libraries.</li>
|
||||
</ul>
|
||||
|
||||
<p>Other topics related to boost development may be acceptable, at the
|
||||
discretion of moderators. If unsure, go ahead and post. The moderators will
|
||||
let you know.</p>
|
||||
|
||||
<h2><a name="unacceptable" id="unacceptable"></a>Unacceptable Topics</h2>
|
||||
|
||||
<ul>
|
||||
<li>Advertisements for commercial products.</li>
|
||||
|
||||
<li>Requests for help getting non-boost code to compile with your
|
||||
compiler. Try the comp.lang.c++.moderated newsgroup instead.</li>
|
||||
|
||||
<li>Requests for help interpreting the C++ standard. Try the comp.std.c++
|
||||
newsgroup instead.</li>
|
||||
|
||||
<li>Job offers.</li>
|
||||
|
||||
<li>Requests for solutions to homework assignments.</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="effective" id="effective"></a>Effective Posting</h2>
|
||||
|
||||
<p>Most Boost mailing lists host a great deal of traffic, so your post is
|
||||
usually competing for attention with many other communications. This
|
||||
section describes how to make sure it has the desired impact.</p>
|
||||
|
||||
<h3>Well-Crafted Posting is Worth the Effort</h3>
|
||||
|
||||
<p>Don't forget, you're a single writer but there are many readers, and you
|
||||
want them to stay interested in what you're saying. Saving your readers a
|
||||
little time and effort is usually worth the extra time you spend when
|
||||
writing a message. Also, boost discussions are saved for posterity, as
|
||||
rationales and history of the work we do. A post's usefulness in the future
|
||||
is determined by its readability.</p>
|
||||
|
||||
<h3>Put the Library Name in the Subject Line</h3>
|
||||
|
||||
<p>When your post is related to a particular Boost library, it's helpful to
|
||||
put the library name in square brackets at the beginning of the subject
|
||||
line, e.g.</p>
|
||||
|
||||
<blockquote>
|
||||
Subject: [Regex] Why doesn't this pattern match?
|
||||
</blockquote>The Boost developers' list is a high-volume mailing list, and
|
||||
most maintainers don't have time to read every message. A tag on the
|
||||
subject line will help ensure the right people see your post.
|
||||
|
||||
<p><a name="tabs" id="tabs"></a></p>
|
||||
|
||||
<h3>Don't Use Tabs</h3>If you use tabs to indent your source code, convert
|
||||
them to spaces before inserting the code in a posting. Something in the
|
||||
processing chain usually strips all the indentation and leaves a mess
|
||||
behind.
|
||||
|
||||
<p><a name="longlines" id="longlines"></a></p>
|
||||
|
||||
<h3>Limit Line Length</h3>If you put source code in your postings and your
|
||||
mailer wraps long lines automatically, either keep the code narrow or
|
||||
insert the code as an (inline, if possible) attachment. That will help
|
||||
ensure others can read what you've posted.
|
||||
|
||||
<p><a name="quoting" id="quoting"></a></p>
|
||||
|
||||
<h3>Don't Overquote</h3>Please <b>prune extraneous quoted text</b> from
|
||||
replies so that only the relevant parts are included. Some people have to
|
||||
pay for, or wait for, each byte that they download from the list. More
|
||||
importantly, it will save time and make your post more valuable when
|
||||
readers do not have to find out which exact part of a previous message you
|
||||
are responding to.
|
||||
|
||||
<h3>Use a Readable Quotation Style</h3>
|
||||
|
||||
<p>A common and very useful approach is to cite the small fractions of the
|
||||
message you are actually responding to and to put your response directly
|
||||
beneath each citation, with a blank line separating them for
|
||||
readability:</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
<i>Person-you're-replying-to</i> wrote:
|
||||
|
||||
> Some part of a paragraph that you wish to reply to goes
|
||||
> here; there may be several lines.
|
||||
|
||||
Your response to that part of the message goes here. There may,
|
||||
of course, be several lines.
|
||||
|
||||
> The second part of the paragraph that is relevant to your
|
||||
> reply goes here; agiain there may be several lines.
|
||||
|
||||
Your response to the second part of the message goes here.
|
||||
...
|
||||
|
||||
</pre>
|
||||
</blockquote>For more information about effective use of quotation in
|
||||
posts, see <a href="http://www.netmeister.org/news/learn2quote.html">this
|
||||
helpful guide</a>.
|
||||
|
||||
<h3>Keep the Formatting of Quotations Consistent</h3>
|
||||
|
||||
<p>Some email and news clients use poor word wrapping algorithms that leave
|
||||
successive lines from the same quotation with differing numbers of leading
|
||||
"<tt>></tt>" characters. <b>Microsoft Outlook</b> and <b>Outlook
|
||||
Express</b>, and some web clients, are especially bad about this. If your
|
||||
client offends in this way, please take the effort to clean up the mess it
|
||||
makes in quoted text. Remember, even if you didn't write the original text,
|
||||
it's <i>your</i> posting; whether you get your point across depends on its
|
||||
readability.</p>
|
||||
|
||||
<p>The Microsoft clients also create an unusually verbose header at the
|
||||
beginning of the original message text and leave the cursor at the
|
||||
beginning of the message, which encourages users to write their replies
|
||||
before all of the quoted text rather than putting the reply in context.
|
||||
Fortunately, Dominic Jain has written a utility that fixes all of these
|
||||
problems automatically: <a href=
|
||||
"http://home.in.tum.de/~jain/software/outlook-quotefix/">Outlook
|
||||
Quotefix</a> for Outlook Users and <a href=
|
||||
"http://home.in.tum.de/~jain/software/oe-quotefix/">OE QuoteFix</a> for
|
||||
users of Outlook Express.</p>
|
||||
|
||||
<h3>Summarizing and Referring to Earlier Messages</h3>
|
||||
|
||||
<p>A summary of the foregoing thread is only needed after a long
|
||||
discussion, especially when the topic is drifting or a result has been
|
||||
achieved in a discussion. The mail system will do the tracking that is
|
||||
needed to enable mail readers to display message threads (and every decent
|
||||
mail reader supports that).</p>
|
||||
|
||||
<p>If you ever have to refer to single message earlier in a thread or in a
|
||||
different thread then you can use a URL to the <a href=
|
||||
"mailing_lists.htm#archive">message archives</a>. To help to keep those
|
||||
URLs short, you can use <a href="http://www.tinyurl.com">tinyurl.com</a>.
|
||||
Citing the relevant portion of a message you link to is often helpful (if
|
||||
the citation is small).</p>
|
||||
|
||||
<h3>Maintain the Integrity of Discussion Threads</h3>
|
||||
|
||||
<p><b>When starting a new topic, always send a fresh message</b>, rather
|
||||
than beginning a reply to some other message and replacing the subject and
|
||||
body. Many mailers are able to detect the thread you started with and will
|
||||
show the new message as part of the original thread, which probably isn't
|
||||
what you intended. Follow this guideline for your own sake as well as for
|
||||
others'. Often, people scanning for relevant messages will decide they're
|
||||
done with a topic and hide or kill the entire thread: your message will be
|
||||
missed, and you won't get the response you're looking for.</p>
|
||||
|
||||
<p>By the same token, <b>When replying to an existing message, use your
|
||||
mailer's "Reply" function</b>, so that the reply shows up as part of the
|
||||
same discussion thread.</p>
|
||||
|
||||
<p><b>Do not reply to digests</b> if you are a digest delivery subscriber.
|
||||
Your reply will not be properly threaded and will probably have the wrong
|
||||
subject line. Instead, you can reply through the <a href=
|
||||
"http://news.gmane.org/gmane.comp.lib.boost.devel">GMane web
|
||||
interface</a>.</p>
|
||||
|
||||
<h3>Keep The Size of Your Posting Manageable</h3>
|
||||
|
||||
<p>The mailing list software automatically limits message and attachment
|
||||
size to a reasonable amount, typically 75K, which is adjusted from
|
||||
time-to-time by the moderators. This limit is a courtesy to those who rely
|
||||
on dial-up Internet access.</p>
|
||||
|
||||
<h2><a name="behavior" id="behavior"></a>Prohibited Behavior</h2>
|
||||
|
||||
<p>Prohibited behavior will not be tolerated. The moderators will ban
|
||||
postings by abusers.</p>
|
||||
|
||||
<h3>Flame wars</h3>
|
||||
|
||||
<p>Personal insults, argument for the sake of argument, and all the other
|
||||
behaviors which fall into the "flame war" category are prohibited.
|
||||
Discussions should focus on technical arguments, not the personality traits
|
||||
or motives of participants.</p>
|
||||
|
||||
<h3>Third-party attacks</h3>
|
||||
|
||||
<p>Attacks on third parties such as software vendors, hardware vendors, or
|
||||
any other organizations, are prohibited. Boost exists to unite and serve
|
||||
the entire C++ community, not to disparage the work of others.</p>
|
||||
|
||||
<p>Does this mean that we ban the occasional complaint or wry remark about
|
||||
a troublesome compiler? No, but be wary of overdoing it.</p>
|
||||
|
||||
<h3>Off-topic posts</h3>
|
||||
|
||||
<p>Discussions which stray from the acceptable topics are strongly
|
||||
discouraged. While off-topic posts are often well meaning and not as
|
||||
individually corrosive as other abuses, cumulatively the distraction
|
||||
damages the effectiveness of discussion.</p>
|
||||
|
||||
<h2><a name="culture" id="culture"></a>Culture</h2>
|
||||
|
||||
<p>In addition to technical skills, Boost members value collaboration,
|
||||
acknowledgement of the help of others, and a certain level of politeness.
|
||||
Boost membership is very international, and ranges widely in age and other
|
||||
characteristics. Think of discussion as occurring among colleagues in a
|
||||
widely read forum, rather than among a few close friends.</p>
|
||||
|
||||
<p>Always remember that the cumulative effort spent by people reading your
|
||||
contribution scales with the (already large) number of boost members. Thus,
|
||||
do invest time and effort to make your message as readable as possible.
|
||||
Adhere to English syntax and grammar rules such as proper capitalization.
|
||||
Avoid copious informalism, colloquial language, or abbreviations, they may
|
||||
not be understood by all readers. Re-read your message before submitting
|
||||
it.</p>
|
||||
|
||||
<h2>Guidelines for Effective Discussions</h2>
|
||||
|
||||
<p>Apply social engineering to prevent heated technical discussion from
|
||||
degenerating into a shouting match, and to actively encourage the
|
||||
cooperation upon which Boost depends.</p>
|
||||
|
||||
<ul>
|
||||
<li>Questions help. If someone suggests something that you don't think
|
||||
will work, then replying with a question like "will that compile?" or
|
||||
"won't that fail to compile, or am I missing something?" is a lot
|
||||
smoother than "That's really stupid - it won't compile." Saying
|
||||
"that fails to compile for me, and seems to violate section n.n.n of the
|
||||
standard" would be yet another way to be firm without being
|
||||
abrasive.</li>
|
||||
|
||||
<li>If most of the discussion has been code-free generalities, posting a
|
||||
bit of sample code can focus people on the practical issues.</li>
|
||||
|
||||
<li>If most of the discussion has been in terms of specific code, try to
|
||||
talk a bit about hidden assumptions and generalities that may be
|
||||
preventing discussion closure.</li>
|
||||
|
||||
<li>Taking a time-out is often effective. Just say: "Let me think about
|
||||
that for a day or two. Let's take a time-out to digest the discussion so
|
||||
far."</li>
|
||||
</ul>
|
||||
|
||||
<p>Avoid <i><b>Parkinson's Bicycle Shed</b></i>. Parkinson described a
|
||||
committee formed to oversee design of an early nuclear power plant. There
|
||||
were three agenda items - when to have tea, where to put the bicycle shed,
|
||||
and how to ensure nuclear safety. Tea was disposed of quickly as
|
||||
trivial. Nuclear safety was discussed for only an hour - it was so
|
||||
complex, scary, and technical that even among experts few felt comfortable
|
||||
with the issues. Endless days were then spent discussing construction of
|
||||
the bicycle shed (the parking lot would be the modern equivalent) because
|
||||
everyone though they understood the issues and felt comfortable discussing
|
||||
them. </p>
|
||||
|
||||
<h2><a name="lib_names" id="lib_names"></a>Library Names</h2>
|
||||
|
||||
<p>In order to ensure a uniform presentation in books and articles, we have
|
||||
adopted a convention for referring to Boost libraries. Library names can
|
||||
either be written in a compact form with a dot, as "Boost.<i>Name</i>", or
|
||||
in a long form as "the Boost <i>Name</i> library." For example:</p>
|
||||
|
||||
<blockquote>
|
||||
<b>Boost.Python</b> serves a very different purpose from <b>the Boost
|
||||
Graph library</b>.
|
||||
</blockquote>Note that the word "library" is not part of the name, and as
|
||||
such isn't capitalized.
|
||||
|
||||
<p>Please take care to avoid confusion in discussions between libraries
|
||||
that have been accepted into Boost and those that have not. Acceptance as a
|
||||
Boost library indicates that the code and design have passed through our
|
||||
peer-review process; failing to make the distinction devalues the hard work
|
||||
of library authors who've gone through that process. Here are some
|
||||
suggested ways to describe potential Boost libraries:</p>
|
||||
|
||||
<ul>
|
||||
<li>the proposed Boost <i>Name</i> library</li>
|
||||
|
||||
<li>the Boost.<i>Name</i> candidate</li>
|
||||
|
||||
<li>the <i>Name</i> library (probably the best choice where
|
||||
applicable)</li>
|
||||
</ul>
|
||||
|
||||
<p>Note that this policy only applies to discussions, not to the
|
||||
documentation, directory structure, or even identifiers in the code of
|
||||
potential Boost libraries.</p>
|
||||
<hr>
|
||||
|
||||
<p><a href="http://validator.w3.org/check?uri=referer"><img border="0" src=
|
||||
"http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01 Transitional"
|
||||
height="31" width="88"></a></p>
|
||||
|
||||
<p>Revised
|
||||
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->04 December, 2006<!--webbot bot="Timestamp" endspan i-checksum="38514" --></p>
|
||||
|
||||
<p><i>Copyright © 2000-2005 Beman Dawes, Rob Stewart, and David Abrahams</i></p>
|
||||
|
||||
<p><i>Distributed under the Boost Software License, Version 1.0. (See
|
||||
accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy
|
||||
at <a href=
|
||||
"http://www.boost.org/LICENSE_1_0.txt">www.boost.org/LICENSE_1_0.txt</a>)</i></p>
|
||||
</body>
|
||||
</html>
|
@ -1,240 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Cygwin (vers 1st April 2002), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=windows-1252">
|
||||
|
||||
<title>Error and Exception Handling</title>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<h1>Error and Exception Handling</h1>
|
||||
|
||||
<h2>References</h2>
|
||||
|
||||
<p>The following paper is a good introduction to some of the issues of
|
||||
writing robust generic components:</p>
|
||||
|
||||
<blockquote>
|
||||
<a href="generic_exception_safety.html">D. Abrahams: ``Exception Safety
|
||||
in Generic Components''</a>, originally published in <a href=
|
||||
"http://www.springer.de/cgi-bin/search_book.pl?isbn=3-540-41090-2">M.
|
||||
Jazayeri, R. Loos, D. Musser (eds.): Generic Programming, Proc. of a
|
||||
Dagstuhl Seminar, Lecture Notes on Computer Science. Volume. 1766</a>
|
||||
</blockquote>
|
||||
|
||||
<h2>Guidelines</h2>
|
||||
|
||||
<h3>When should I use exceptions?</h3>
|
||||
|
||||
<p>The simple answer is: ``whenever the semantic and performance
|
||||
characteristics of exceptions are appropriate.''</p>
|
||||
|
||||
<p>An oft-cited guideline is to ask yourself the question ``is this an
|
||||
exceptional (or unexpected) situation?'' This guideline has an attractive
|
||||
ring to it, but is usually a mistake. The problem is that one person's
|
||||
``exceptional'' is another's ``expected'': when you really look at the
|
||||
terms carefully, the distinction evaporates and you're left with no
|
||||
guideline. After all, if you check for an error condition, then in some
|
||||
sense you expect it to happen, or the check is wasted code.</p>
|
||||
|
||||
<p>A more appropriate question to ask is: ``do we want stack
|
||||
unwinding here?'' Because actually handling an exception is likely
|
||||
to be significantly slower than executing mainline code, you
|
||||
should also ask: ``Can I afford stack unwinding here?'' For
|
||||
example, a desktop application performing a long computation might
|
||||
periodically check to see whether the user had pressed a cancel
|
||||
button. Throwing an exception could allow the operation to be
|
||||
cancelled gracefully. On the other hand, it would probably be
|
||||
inappropriate to throw and <i>handle</i> exceptions in the inner
|
||||
loop of this computation because that could have a significant
|
||||
performance impact. The guideline mentioned above has a grain of
|
||||
truth in it: in time critical code, throwing an exception
|
||||
should <em>be</em> the exception, not the rule.</p>
|
||||
|
||||
<h3>How should I design my exception classes?</h3>
|
||||
|
||||
<ol>
|
||||
<li><b>Derive your exception class
|
||||
from <code>std::exception</code></b>. Except in *very* rare
|
||||
circumstances where you can't afford the cost of a virtual
|
||||
table,
|
||||
<code>std::exception</code> makes a reasonable exception base class,
|
||||
and when used universally, allows programmers to catch "everything"
|
||||
without resorting to <code>catch(...)</code>. For more about
|
||||
<code>catch(...)</code>, see below.
|
||||
|
||||
<li><b>Use <i>virtual</i> inheritance.</b> This insight is due
|
||||
to Andrew Koenig. Using virtual inheritance from your
|
||||
exception's base class(es) prevents ambiguity problems at the
|
||||
catch-site in case someone throws an exception derived from
|
||||
multiple bases which have a base class in common:
|
||||
|
||||
<pre>
|
||||
#include <iostream>
|
||||
struct my_exc1 : std::exception { char const* what() const throw(); };
|
||||
struct my_exc2 : std::exception { char const* what() const throw(); };
|
||||
struct your_exc3 : my_exc1, my_exc2 {};
|
||||
|
||||
int main()
|
||||
{
|
||||
try { throw your_exc3(); }
|
||||
catch(std::exception const& e) {}
|
||||
catch(...) { std::cout << "whoops!" << std::endl; }
|
||||
}
|
||||
</pre>
|
||||
|
||||
The program above prints <code>"whoops"</code> because the
|
||||
C++ runtime can't resolve which <code>exception</code> instance to
|
||||
match in the first catch clause.
|
||||
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<b><i>Don't</i> embed a std::string object</b> or any other data
|
||||
member or base class whose copy constructor could throw an exception.
|
||||
That could lead directly to std::terminate() at the throw point.
|
||||
Similarly, it's a bad idea to use a base or member whose ordinary
|
||||
constructor(s) might throw, because, though not necessarily fatal to
|
||||
your program, you may report a different exception than intended from
|
||||
a <i>throw-expression</i> that includes construction such as:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
throw some_exception();
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>There are various ways to avoid copying string objects when
|
||||
exceptions are copied, including embedding a fixed-length buffer in
|
||||
the exception object, or managing strings via reference-counting.
|
||||
However, consider the next point before pursuing either of these
|
||||
approaches.</p>
|
||||
</li>
|
||||
|
||||
<li><b>Format the <code>what()</code> message on demand</b>, if you
|
||||
feel you really must format the message. Formatting an exception error
|
||||
message is typically a memory-intensive operation that could
|
||||
potentially throw an exception. This is an operation best delayed until
|
||||
after stack unwinding has occurred, and presumably, released some
|
||||
resources. It's a good idea in this case to protect your
|
||||
<code>what()</code> function with a <code>catch(...)</code> block so
|
||||
that you have a fallback in case the formatting code throws</li>
|
||||
|
||||
<li><b>Don't worry <i>too</i> much about the <code>what()</code>
|
||||
message</b>. It's nice to have a message that a programmer stands a
|
||||
chance of figuring out, but you're very unlikely to be able to compose
|
||||
a relevant and <i>user</i>-comprehensible error message at the point an
|
||||
exception is thrown. Certainly, internationalization is beyond the
|
||||
scope of the exception class author. <a href=
|
||||
"../people/peter_dimov.htm">Peter Dimov</a> makes an excellent argument
|
||||
that the proper use of a <code>what()</code> string is to serve as a
|
||||
key into a table of error message formatters. Now if only we could get
|
||||
standardized <code>what()</code> strings for exceptions thrown by the
|
||||
standard library...</li>
|
||||
|
||||
<li><b>Expose relevant information about the cause of the error</b> in
|
||||
your exception class' public interface. A fixation on the
|
||||
<code>what()</code> message is likely to mean that you neglect to
|
||||
expose information someone might need in order to make a coherent
|
||||
message for users. For example, if your exception reports a numeric
|
||||
range error, it's important to have the actual numbers involved
|
||||
available <i>as numbers</i> in the exception class' public interface
|
||||
where error reporting code can do something intelligent with them. If
|
||||
you only expose a textual representation of those numbers in the
|
||||
<code>what()</code> string, you will make life very difficult for
|
||||
programmers who need to do something more (e.g. subtraction) with them
|
||||
than dumb output.</li>
|
||||
|
||||
<li><b>Make your exception class immune to double-destruction</b> if
|
||||
possible. Unfortunately, several popular compilers occasionally cause
|
||||
exception objects to be destroyed twice. If you can arrange for that to
|
||||
be harmless (e.g. by zeroing deleted pointers) your code will be more
|
||||
robust.</li>
|
||||
</ol>
|
||||
|
||||
<h3>What About Programmer Errors?</h3>
|
||||
|
||||
<p>As a developer, if I have violated a precondition of a library I'm
|
||||
using, I don't want stack unwinding. What I want is a core dump or the
|
||||
equivalent - a way to inspect the state of the program at the exact point
|
||||
where the problem was detected. That usually means <tt>assert()</tt> or
|
||||
something like it.</p>
|
||||
|
||||
<p>Sometimes it is necessary to have resilient APIs which can stand up to
|
||||
nearly any kind of client abuse, but there is usually a significant cost
|
||||
to this approach. For example, it usually requires that each object used
|
||||
by a client be tracked so that it can be checked for validity. If you
|
||||
need that sort of protection, it can usually be provided as a layer on
|
||||
top of a simpler API. Beware half-measures, though. An API which promises
|
||||
resilience against some, but not all abuse is an invitation to disaster.
|
||||
Clients will begin to rely on the protection and their expectations will
|
||||
grow to cover unprotected parts of the interface.</p>
|
||||
|
||||
<p><b>Note for Windows developers</b>: unfortunately, the native
|
||||
exception-handling used by most Windows compilers actually throws an
|
||||
exception when you use <tt>assert()</tt>. Actually, this is true of other
|
||||
programmer errors such as segmentation faults and divide-by-zero errors.
|
||||
One problem with this is that if you use JIT (Just In Time) debugging,
|
||||
there will be collateral exception-unwinding before the debugger comes up
|
||||
because <code>catch(...)</code> will catch these not-really-C++
|
||||
exceptions. Fortunately, there is a simple but little-known workaround,
|
||||
which is to use the following incantation:</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
extern "C" void straight_to_debugger(unsigned int, EXCEPTION_POINTERS*)
|
||||
{
|
||||
throw;
|
||||
}
|
||||
extern "C" void (*old_translator)(unsigned, EXCEPTION_POINTERS*)
|
||||
= _set_se_translator(straight_to_debugger);
|
||||
</pre>
|
||||
</blockquote>
|
||||
This technique doesn't work if the SEH is raised from within a catch
|
||||
block (or a function called from within a catch block), but it still
|
||||
eliminates the vast majority of JIT-masking problems.
|
||||
|
||||
<h3>How should I handle exceptions?</h3>
|
||||
|
||||
<p>Often the best way to deal with exceptions is to not handle them at
|
||||
all. If you can let them pass through your code and allow destructors to
|
||||
handle cleanup, your code will be cleaner.</p>
|
||||
|
||||
<h4>Avoid <code>catch(...)</code> when possible</h4>
|
||||
Unfortunately, operating systems other than Windows also wind non-C++
|
||||
"exceptions" (such as thread cancellation) into the C++ EH machinery, and
|
||||
there is sometimes no workaround corresponding to the
|
||||
<code>_set_se_translator</code> hack described above. The result is that
|
||||
<code>catch(...)</code> can have the effect of making some unexpected
|
||||
system notification at a point where recovery is impossible look just
|
||||
like a C++ exception thrown from a reasonable place, invalidating the
|
||||
usual safe assumptions that destructors and catch blocks have taken valid
|
||||
steps to ensure program invariants during unwinding.
|
||||
|
||||
<p>I reluctantly concede this point to Hillel Y. Sims, after many
|
||||
long debates in the newsgroups: until all OSes are "fixed", if
|
||||
every exception were derived from <code>std::exception</code> and
|
||||
everyone substituted
|
||||
<code>catch(std::exception&)</code> for <code>catch(...)</code>, the
|
||||
world would be a better place.</p>
|
||||
|
||||
<p>Sometimes, <code>catch(...)</code>, is still the most appropriate
|
||||
pattern, in spite of bad interactions with OS/platform design choices. If
|
||||
you have no idea what kind of exception might be thrown and you really
|
||||
<i>must</i> stop unwinding it's probably still your best bet. One obvious
|
||||
place where this occurs is at language boundaries.</p>
|
||||
<hr>
|
||||
|
||||
<p>© Copyright David Abrahams 2001-2003. All rights reserved.</p>
|
||||
|
||||
<p>Revised
|
||||
<!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan -->
|
||||
21 August, 2003<!--webbot bot="Timestamp" endspan i-checksum="34359" -->
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
|
@ -107,7 +107,15 @@ div.admonition p.admonition-title {
|
||||
needs your evaluation of the library. If you identify problems along
|
||||
the way, please note if they are minor, serious, or showstoppers.</p>
|
||||
|
||||
<p>Here are some questions you might want to answer in your review:</p>
|
||||
<p>The goal of a Boost library review is to improve the library through
|
||||
constructive criticism, and at the end a decision must be made: is the
|
||||
library good enough at this point to accept into Boost? If not, we hope to
|
||||
have provided enough constructive criticism for it to be improved and
|
||||
accepted at a later time. The Serialization library is a good example of how
|
||||
constructive criticism resulted in revisions resulting in an excellent
|
||||
library that was accepted in its second review.</p>
|
||||
|
||||
<p>Here are some questions you might want to answer in your review:</p>
|
||||
|
||||
<ul>
|
||||
<li>What is your evaluation of the design?<br></li>
|
||||
@ -136,7 +144,21 @@ div.admonition p.admonition-title {
|
||||
your overall opinion.</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="Results" id="Results">Results</a></h2>
|
||||
<p>Many reviews include questions for library authors. Authors are
|
||||
interested in defending their library against your criticisms; otherwise
|
||||
they would not have brought their library up for review. If you don't get a
|
||||
response to your question quickly, be patient; if it takes too long or you
|
||||
don't get an answer you feel is sufficient, ask again or try to rephrase the
|
||||
question. Do remember that English is not the native language for many
|
||||
Boosters, and that can cause misunderstandings.<br>
|
||||
<br>
|
||||
E-mail is a poor communication medium, and even if messages rarely get lost
|
||||
in transmission, they often get drowned in the deluge of other messages.
|
||||
Don't assume that an unanswered message means you're being ignored. Given
|
||||
constructively, criticism will be taken better and have more positive
|
||||
effects, and you'll get the answers you want.</p>
|
||||
|
||||
<h2><a name="Results">Results</a></h2>
|
||||
|
||||
<p>At the conclusion of the comment period, the Review Manager will post a
|
||||
message to the mailing list saying if the library has been accepted or
|
||||
@ -192,9 +214,12 @@ div.admonition p.admonition-title {
|
||||
<li>Follows review discussions regarding the library, moderating or
|
||||
answering questions as needed.</li>
|
||||
|
||||
<li>Asks the <a href="#Wizard">review wizard</a> for permission to extend
|
||||
the review schedule if it appears that too few reviews will be submitted
|
||||
during the review period.</li>
|
||||
<li>Asks the <a href="#Wizard">review wizard</a> for permission
|
||||
to extend the review schedule if it appears that too few reviews will
|
||||
be submitted during the review period.</li>
|
||||
|
||||
<li>Decides if there is consensus to accept the library, and if there
|
||||
are any conditions attached.</li>
|
||||
|
||||
<li>Decides if there is consensus to accept the library, and if there are
|
||||
any conditions attached.</li>
|
||||
@ -256,9 +281,12 @@ div.admonition p.admonition-title {
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
<li>Maintains a schedule of both past and pending reviews, in the form of
|
||||
the <a href="formal_review_schedule.html">Review Schedule</a> web
|
||||
page.</li>
|
||||
<li>Monitors the general review process, and makes minor adjustments as
|
||||
needed, or queries the list about possible major adjustments.</li>
|
||||
</ul>
|
||||
The role of Boost Review Wizard is currently played by John
|
||||
Phillips (phillips at mps dot ohio-state dot edu) and Ronald
|
||||
Garcia (garcia at cs dot indiana dot edu).
|
||||
|
||||
<li>Resolves questions from review managers and library submitters, who
|
||||
sometimes want a third opinion on questions such as "Should we extend the
|
||||
@ -270,7 +298,8 @@ div.admonition p.admonition-title {
|
||||
"mailto:reportbase@yahoo.com">Tom Brinkman</a> and Ronald Garcia (garcia at
|
||||
cs dot indiana dot edu).
|
||||
|
||||
<h2><a name="Fast-Track" id="Fast-Track">Fast Track Reviews</a></h2>
|
||||
<p>Revised
|
||||
<!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan -->10 October, 2006<!--webbot bot="Timestamp" endspan i-checksum="38930" --></p>
|
||||
|
||||
<p>To qualify for fast track review:</p>
|
||||
|
||||
|
@ -1,17 +1,16 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
|
||||
"http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<meta http-equiv="Content-Language" content="en-us">
|
||||
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
||||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
|
||||
<title>Formal Review Schedule</title>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
|
||||
<table border="1" bgcolor="#007F7F" cellpadding="2">
|
||||
<table border="1" bgcolor="#007F7F" cellpadding="2" summary="Links">
|
||||
<tr>
|
||||
<td bgcolor="#FFFFFF">
|
||||
<img src="../boost.png" alt="boost.png (6897 bytes)" width="277" height="86"></td>
|
||||
@ -34,7 +33,8 @@ track review manager assignments and libraries reviewed but not yet posted on
|
||||
the web site. There is often a lag between acceptance and site posting as
|
||||
authors address issues raised in the formal review.</p>
|
||||
<h2><a name="Schedule">Schedule</a></h2>
|
||||
<table border="1" cellpadding="5" cellspacing="0">
|
||||
|
||||
<table border="1" cellpadding="5" cellspacing="0" summary="Review Queue">
|
||||
<tr>
|
||||
<td valign="top"><b>Submission</b></td>
|
||||
<td valign="top"><b>Submitter</b></td>
|
||||
@ -46,26 +46,144 @@ authors address issues raised in the formal review.</p>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Function Types (Re-review)</td>
|
||||
<td>Tobias Schwinger</td>
|
||||
<td>Boost Sandbox Vault</td>
|
||||
<td>Tom Brinkman</td>
|
||||
<td>Finite State Machines</td>
|
||||
<td>Andrey Semashev</td>
|
||||
<td><a href="http://tinyurl.com/yjozfn">
|
||||
Boost Sandbox Vault</a></td>
|
||||
<td>Martin Vuille</td>
|
||||
<td>-</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Message Passing</td>
|
||||
<td>Doug Gregor</td>
|
||||
<td>
|
||||
<a href="http://www.osl.iu.edu/~dgregor/boost.mpi/boost-mpi-20060628.tgz">
|
||||
http://www.osl.iu.edu/~dgregor/boost.mpi/boost-mpi-20060628.tgz</a></td>
|
||||
<td>Floating Point Utilities</td>
|
||||
<td>Johan Råde</td>
|
||||
<td><a href="http://boost-consulting.com/vault/index.php?directory=Math%20-%20Numerics">
|
||||
Boost Sandbox Vault</a></td>
|
||||
<td>Needed</td>
|
||||
<td>-</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Switch</td>
|
||||
<td>Steven Watanabe</td>
|
||||
<td><a href="http://boost-consulting.com/vault/index.php?action=downloadfile&filename=mcs_units_v0.7.1.zip&directory=Units">
|
||||
Boost Sandbox Vault</a> </td>
|
||||
<td>Stejpan Rajko</td>
|
||||
<td>January 5, 2008 - January 9, 2008</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Property Map (fast-track)</td>
|
||||
<td>Andrew Sutton</td>
|
||||
<td><a href="http://svn.boost.org/svn/boost/sandbox/graph-v2">
|
||||
Boost Sandbox</a></td>
|
||||
<td>Jeremy Siek</td>
|
||||
<td>-</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Graph (fast-track)</td>
|
||||
<td>Andrew Sutton</td>
|
||||
<td><a href="http://svn.boost.org/svn/boost/sandbox/graph-v2">
|
||||
Boost Sandbox</a></td>
|
||||
<td>Jeremy Siek</td>
|
||||
<td>-</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Forward (fast-track)</td>
|
||||
<td>Tobias Schwinger</td>
|
||||
<td><a href="http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=X-Files">
|
||||
Boost Sandbox Vault</a></td>
|
||||
<td>John Torjo</td>
|
||||
<td>January 14, 2008 - January 18, 2008</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Singleton (fast-track)</td>
|
||||
<td>Tobias Schwinger</td>
|
||||
<td><a href="http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=X-Files">
|
||||
Boost Sandbox Vault</a></td>
|
||||
<td>John Torjo</td>
|
||||
<td>December 3, 2007 - December 7, 2007</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Factory (fast-track)</td>
|
||||
<td>Tobias Schwinger</td>
|
||||
<td><a href="http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=X-Files">
|
||||
Boost Sandbox Vault</a></td>
|
||||
<td>John Torjo</td>
|
||||
<td>December 17, 2007 - December 21, 2007</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Lexer</td>
|
||||
<td>Ben Hanson</td>
|
||||
<td><a href="http://boost-consulting.com/vault/index.php?action=downloadfile&filename=boost.lexer.zip&directory=Strings%20-%20Text%20Processing&">
|
||||
Boost Sandbox Vault</a></td>
|
||||
<td>Hartmut Kaiser</td>
|
||||
<td>-</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Thread-Safe Signals</td>
|
||||
<td>Frank Hess</td>
|
||||
<td><a href="http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directory=thread_safe_signals">
|
||||
Boost Sandbox Vault</a></td>
|
||||
<td>Needed</td>
|
||||
<td>-</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Logging</td>
|
||||
<td>John Torjo</td>
|
||||
<td><a href="http://torjo.com/log2/">http://torjo.com/log2/</a></td>
|
||||
<td>Gennadiy Rozental</td>
|
||||
<td>February 4, 2008 - February 13, 2008</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Flyweight</td>
|
||||
<td>Joaquín Mª López Muñoz</td>
|
||||
<td><a href="http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=flyweight.zip&directory=Patterns">
|
||||
Boost Sandbox Vault</a></td>
|
||||
<td>Ion Gaztañaga</td>
|
||||
<td>January 21, 2008 - January 30, 2008</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Unordered Containers</td>
|
||||
<td>Daniel James</td>
|
||||
<td><a href="http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=unordered.zip&directory=Containers">Boost Sandbox Vault</a></td>
|
||||
<td>Ion Gaztañaga</td>
|
||||
<td>December 7, 2007 - December 16, 2007</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Boost.Range (Update)</td>
|
||||
<td>Neil Groves</td>
|
||||
<td><a
|
||||
href="http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=range_ex.zip&directory=">
|
||||
Boost Sandbox Vault</a></td>
|
||||
<td>Needed</td>
|
||||
<td>-</td>
|
||||
</tr>
|
||||
|
||||
<!--
|
||||
<tr>
|
||||
<td></td> Library Name
|
||||
<td></td> Library Author
|
||||
<td><a href=""></a></td> URL
|
||||
<td></td> Review Manager (or "NEEDED")
|
||||
<td>-</td> Review Dates (or "-")
|
||||
</tr>
|
||||
-->
|
||||
|
||||
</table>
|
||||
|
||||
<h2>Past Review Results and Milestones</h2>
|
||||
<table border="1" cellpadding="5" cellspacing="0">
|
||||
<table border="1" cellpadding="5" cellspacing="0"summary="Review Results">
|
||||
<tr>
|
||||
<td valign="top"><b>Submission</b></td>
|
||||
<td valign="top"><b>Submitter</b></td>
|
||||
@ -76,6 +194,151 @@ authors address issues raised in the formal review.</p>
|
||||
<td valign="top"><b>Result</b></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Review Wizard Status Report</td>
|
||||
<td></td>
|
||||
<td>Ronald Garcia</td>
|
||||
<td>2007 November 16</td>
|
||||
<td><a href="report-nov-2007.html">Report</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Exception</td>
|
||||
<td>Emil Dotchevski</td>
|
||||
<td>Tobias Schwinger</td>
|
||||
<td>September 27, 2007 - October 7, 2007</td>
|
||||
<td><a href="http://lists.boost.org/boost-users/2007/11/31912.php">
|
||||
Accepted</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Review Wizard Status Report</td>
|
||||
<td></td>
|
||||
<td>Ronald Garcia</td>
|
||||
<td>2007 September 14</td>
|
||||
<td><a href="report-sep-2007.html">Report</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Scope Exit</td>
|
||||
<td>Alexander Nasonov</td>
|
||||
<td>Jody Hagins</td>
|
||||
<td>August 13, 2007 - August 22, 2007-</td>
|
||||
<td><a href="http://lists.boost.org/boost-announce/2007/08/0139.php">
|
||||
Pending</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Time Series</td>
|
||||
<td>Eric Niebler</td>
|
||||
<td>John R. Phillips</td>
|
||||
<td>July 30, 2007 - August 13, 2007</td>
|
||||
<td><a href="http://lists.boost.org/boost-announce/2007/08/0142.php">
|
||||
Accepted</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Boost 1.34.1 Released</td>
|
||||
<td></td>
|
||||
<td>Thomas Witt</td>
|
||||
<td>July 24, 2007</td>
|
||||
<td><a href="http://lists.boost.org/boost-announce/2007/07/0135.php">
|
||||
Notes</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Boost 1.34.0 Released</td>
|
||||
<td></td>
|
||||
<td>Thomas Witt</td>
|
||||
<td>May 12, 2007</td>
|
||||
<td><a href="http://lists.boost.org/boost-announce/2007/05/0131.php">
|
||||
Notes</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Globally Unique Identifier</td>
|
||||
<td>Andy Tompkins</td>
|
||||
<td>Hartmut Kaiser</td>
|
||||
<td>April 30, 2007 - May 10, 2007</td>
|
||||
<td><a href="http://lists.boost.org/boost-announce/2007/05/0134.php">
|
||||
Accepted Provisionally</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Math Toolkit</td>
|
||||
<td>John Maddock</td>
|
||||
<td>Matthias Schabel</td>
|
||||
<td>April 11, 2007 - April 27, 2007</td>
|
||||
<td><a href="http://lists.boost.org/boost-announce/2007/05/0129.php">
|
||||
Accepted -- Added to SVN</a></td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr>
|
||||
<td>Quantitative Units</td>
|
||||
<td>Matthias Schabel</td>
|
||||
<td>John R. Phillips</td>
|
||||
<td>March 26, 2007 - April 4, 2007</td>
|
||||
<td><a href="http://lists.boost.org/boost-announce/2007/04/0126.php">
|
||||
Accepted</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Intrusive Containers</td>
|
||||
<td>Ion Gaztañaga</td>
|
||||
<td>Joaquín Mª López Muñoz</td>
|
||||
<td>March 12, 2007 - March 21, 2007</td>
|
||||
<td><a href="http://lists.boost.org/boost-announce/2007/04/0122.php">
|
||||
Accepted -- Added to CVS</a></td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr>
|
||||
<td>Bimap</td>
|
||||
<td>Matias Capeletto</td>
|
||||
<td>Ion Gaztañaga</td>
|
||||
<td>February 15 2007- March 2, 2007</td>
|
||||
<td><a href="http://lists.boost.org/Archives/boost/2007/03/117351.php">
|
||||
Accepted -- Added to CVS</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Accumulators</td>
|
||||
<td>Eric Niebler</td>
|
||||
<td>John R. Phillips</td>
|
||||
<td>January 29, 2007 - February 7, 2007</td>
|
||||
<td><a href="http://lists.boost.org/boost-announce/2007/02/0114.php">
|
||||
Accepted</a></td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr>
|
||||
<td>Function Types (Re-review)</td>
|
||||
<td>Tobias Schwinger</td>
|
||||
<td>Tom Brinkman</td>
|
||||
<td>2006 November 6 - 2006 November 17</td>
|
||||
<td><a href="http://lists.boost.org/boost-announce/2006/11/0106.php">
|
||||
Accepted -- Added to CVS</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Generic Image Library</td>
|
||||
<td>Lubomir Bourdev</td>
|
||||
<td>Tom Brinkman</td>
|
||||
<td>2006 October 5 - 2006 October 25</td>
|
||||
<td><a href="http://lists.boost.org/Archives/boost/2006/11/112896.php">
|
||||
Accepted -- Added to CVS</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Message Passing</td>
|
||||
<td>Doug Gregor</td>
|
||||
<td>Jeremy Siek</td>
|
||||
<td>2006 September 6 - 2006 September 15</td>
|
||||
<td><a href="http://lists.boost.org/boost-announce/2006/09/0099.php">
|
||||
Accepted -- Added to CVS</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Physical Quantities System</td>
|
||||
<td>Andy Little</td>
|
||||
@ -90,8 +353,8 @@ authors address issues raised in the formal review.</p>
|
||||
<td>Asger Mangaard</td>
|
||||
<td>Rene Rivera</td>
|
||||
<td>2006 May 15 - 2006 May 24</td>
|
||||
<td><a href="http://lists.boost.org/boost-announce/2006/05/0090.php">
|
||||
Pending</a></td>
|
||||
<td><a href="http://lists.boost.org/boost-announce/2006/10/0104.php">
|
||||
Rejected</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
@ -100,7 +363,7 @@ authors address issues raised in the formal review.</p>
|
||||
<td>Ronald Garcia</td>
|
||||
<td>2006 May 1 - 2006 May 10</td>
|
||||
<td><a href="http://lists.boost.org/boost-announce/2006/06/0094.php">
|
||||
Accepted</a></td>
|
||||
Accepted -- Added to CVS</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
@ -109,7 +372,7 @@ authors address issues raised in the formal review.</p>
|
||||
<td>Thorsten Ottosen</td>
|
||||
<td>2006 April 18 - 2006 April 30</td>
|
||||
<td><a href="http://lists.boost.org/boost-announce/2006/05/0092.php">
|
||||
Accepted</a></td>
|
||||
Accepted -- Added to CVS</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
@ -118,8 +381,9 @@ authors address issues raised in the formal review.</p>
|
||||
<td>Tobias Schwinger</td>
|
||||
<td>2006 April 1 - 2006 April 9</td>
|
||||
<td><a href="http://lists.boost.org/boost-announce/2006/04/0086.php">
|
||||
Accepted</a></td>
|
||||
Accepted -- Added to CVS</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Review Wizard Status Report</td>
|
||||
<td></td>
|
||||
@ -129,13 +393,13 @@ authors address issues raised in the formal review.</p>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Shmem</td>
|
||||
<td>Ion Gaztanaga</td>
|
||||
<td>Shmem (now Interprocess)</td>
|
||||
<td>Ion Gaztañaga</td>
|
||||
<td>Fred Bertsch</td>
|
||||
<td>2006 February 6 - 2006 February 15</td>
|
||||
<td><a
|
||||
href="http://lists.boost.org/boost-announce/2006/02/0083.php">
|
||||
Accepted</a></td>
|
||||
Accepted -- Added to CVS</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
@ -161,7 +425,7 @@ authors address issues raised in the formal review.</p>
|
||||
<td>Jeff Garland</td>
|
||||
<td>2005 December 10 - <br>2005 December 30</td>
|
||||
<td><a href="http://lists.boost.org/Archives/boost/2006/03/102287.php">
|
||||
Accepted</a></td>
|
||||
Accepted -- Added to CVS</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
@ -214,7 +478,7 @@ authors address issues raised in the formal review.</p>
|
||||
<td>John Maddock</td>
|
||||
<td>Beman Dawes</td>
|
||||
<td>2005 September 24 - 2005 October 5</td>
|
||||
<td>Accepted -- added to cvs</td>
|
||||
<td>Accepted -- Added in 1.34</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
@ -222,7 +486,7 @@ authors address issues raised in the formal review.</p>
|
||||
<td>Eric Niebler</td>
|
||||
<td>Thomas Witt</td>
|
||||
<td> 2005 September 8 - 2005 September 18</td>
|
||||
<td>Accepted -- Added to CVS</td>
|
||||
<td>Accepted -- Added in 1.34</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
@ -248,7 +512,7 @@ authors address issues raised in the formal review.</p>
|
||||
<td>Arkadiy Vertleyb and Peder Holt</td>
|
||||
<td>Andy Little</td>
|
||||
<td>2005 May 20 - 2005 May 30</td>
|
||||
<td>Accepted -- Added to CVS</td>
|
||||
<td>Accepted -- Added in 1.34</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
@ -265,7 +529,7 @@ authors address issues raised in the formal review.</p>
|
||||
<td>Eric Niebler</td>
|
||||
<td>Gennadiy Rozental</td>
|
||||
<td>2005 April 25 - 2005 May 1</td>
|
||||
<td>Accepted -- Added to CVS</td>
|
||||
<td>Accepted -- Added in 1.34</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
@ -281,7 +545,7 @@ authors address issues raised in the formal review.</p>
|
||||
<td>Andreas Huber</td>
|
||||
<td>Pavel Vozenilek</td>
|
||||
<td>2005 Feb 23 - 2005 March 9</td>
|
||||
<td>Accepted -- Added to CVS</td>
|
||||
<td>Accepted -- Added in 1.34</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Wave</td>
|
||||
@ -348,29 +612,30 @@ authors address issues raised in the formal review.</p>
|
||||
<td>Accepted -- Added in 1.32</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Container Traits (renamed boost.range)</td>
|
||||
<td>Container Traits (now Range)</td>
|
||||
<td>Thorsten Ottosen</td>
|
||||
<td>Hartmut Kaiser</td>
|
||||
<td>2004 Apr 28 - May 7</td>
|
||||
<td>Accepted -- Added in 1.32</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Indexed Set</td>
|
||||
<td>Joaqu� M L�ez Mu�z</td>
|
||||
<td>Indexed Set (now MultiIndex)</td>
|
||||
<td>Joaquín Mª López Muñoz</td>
|
||||
<td>Pavel Vozenilek</td>
|
||||
<td>2004 Mar 20 - 30</td>
|
||||
<td>Accepted -- Added in 1.32</td>
|
||||
<td><a href="http://lists.boost.org/Archives/boost/2004/04/63582.php">
|
||||
Accepted -- Added in 1.32</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Circular Buffer</td>
|
||||
<td>Jan Gaspar</td>
|
||||
<td>Pavel Vozenilek</td>
|
||||
<td>2004 Mar 5 - 15</td>
|
||||
<td>Accepted -- not added yet</td>
|
||||
<td>Accepted -- Added to CVS</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>enable_if</td>
|
||||
<td>Jaakko Järvi & Jeremiah Willcock & Andrew Lumsdaine</td>
|
||||
<td>Jaakko Järvi & Jeremiah Willcock & Andrew Lumsdaine</td>
|
||||
<td>(fasttrack)</td>
|
||||
<td>Dec 2003</td>
|
||||
<td>Accepted -- added in 1.31</td>
|
||||
@ -461,7 +726,7 @@ authors address issues raised in the formal review.</p>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Minmax</td>
|
||||
<td>Hervé Bronnimann</td>
|
||||
<td>Hervé Bronnimann</td>
|
||||
<td>Thomas Witt</td>
|
||||
<td>28 Sep - 07 Oct 2002</td>
|
||||
<td>Accepted -- added in 1.32</td>
|
||||
@ -475,7 +740,7 @@ authors address issues raised in the formal review.</p>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Interval Arithmetic Library</td>
|
||||
<td>Hervé Bronnimann & Guillaume Melquiond & Sylvain Pion</td>
|
||||
<td>Hervé Bronnimann & Guillaume Melquiond & Sylvain Pion</td>
|
||||
<td>Beman Dawes</td>
|
||||
<td>31 Aug - 09 Sep 2002</td>
|
||||
<td>Accepted -- added in 1.30</td>
|
||||
@ -510,7 +775,7 @@ authors address issues raised in the formal review.</p>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Lambda</td>
|
||||
<td>Jaakko J�vi & Gary Powell</td>
|
||||
<td>Jaakko Järvi & Gary Powell</td>
|
||||
<td>Aleksey Gurtovoy</td>
|
||||
<td>08 - 20 Mar 2002</td>
|
||||
<td>Accepted and added</td>
|
||||
@ -601,7 +866,7 @@ authors address issues raised in the formal review.</p>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Tuples Library</td>
|
||||
<td>Jaakko J�vi</td>
|
||||
<td>Jaakko Järvi</td>
|
||||
<td>Beman Dawes</td>
|
||||
<td>Jun 17 - 26</td>
|
||||
<td>Accepted and added</td>
|
||||
@ -632,7 +897,9 @@ authors address issues raised in the formal review.</p>
|
||||
<p>We try to rotate the task of Review Manager between many experienced Boost
|
||||
members, both to ensure fairness, and to spread the workload. If you would
|
||||
like to volunteer to become a review manager, please contact
|
||||
<a href="mailto:reportbase@gmail.com">Tom Brinkman (Review Wizard)</a>.</p>
|
||||
John Phillips (phillips at mps dot ohio-state dot edu) or Ronald
|
||||
Garcia (garcia at cs dot indiana dot edu).
|
||||
</p>
|
||||
<hr>
|
||||
<p>Revised
|
||||
<!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %b %Y" startspan -->15 Apr 2005<!--webbot bot="Timestamp" endspan i-checksum="15045" -->
|
||||
|
@ -1,683 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
||||
<!-- saved from url=(0052)http://people.ne.mediaone.net/abrahams/abrahams.html -->
|
||||
|
||||
<meta name="generator" content="Microsoft FrontPage 5.0">
|
||||
<title>Exception-Safety in Generic Components</title>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
||||
<meta content="MSHTML 5.50.4522.1800" name="GENERATOR">
|
||||
|
||||
<h1 align="center">Exception-Safety in Generic Components</h1>
|
||||
|
||||
<p align="center"><i><b>Lessons Learned from Specifying Exception-Safety
|
||||
for the C++ Standard Library</b></i>
|
||||
|
||||
<h3 align="center">David Abrahams</h3>
|
||||
|
||||
<h3 align="center"><a href="mailto:david.abrahams@rcn.com">
|
||||
david.abrahams@rcn.com</a></h3>
|
||||
|
||||
<p><b>Abstract.</b> This paper represents the knowledge accumulated in
|
||||
response to a real-world need: that the C++ Standard Template Library
|
||||
exhibit useful and well-defined interactions with exceptions, the
|
||||
error-handling mechanism built-in to the core C++ language. It explores the
|
||||
meaning of exception-safety, reveals surprising myths about exceptions and
|
||||
genericity, describes valuable tools for reasoning about program
|
||||
correctness, and outlines an automated testing procedure for verifying
|
||||
exception-safety.
|
||||
|
||||
<p><b>Keywords:</b> exception-safety, exceptions, STL, C++
|
||||
|
||||
<h2>1 What is exception-safety?</h2>
|
||||
|
||||
<p>Informally, exception-safety in a component means that it exhibits
|
||||
reasonable behavior when an exception is thrown during its execution. For
|
||||
most people, the term ``reasonable'' includes all the usual
|
||||
expectations for error-handling: that resources should not be leaked, and
|
||||
that the program should remain in a well-defined state so that execution
|
||||
can continue. For most components, it also includes the expectation that
|
||||
when an error is encountered, it is reported to the caller.
|
||||
|
||||
<p>More formally, we can describe a component as minimally exception-safe
|
||||
if, when exceptions are thrown from within that component, its invariants
|
||||
are intact. Later on we'll see that at least three different levels of
|
||||
exception-safety can be usefully distinguished. These distinctions can help
|
||||
us to describe and reason about the behavior of large systems.
|
||||
|
||||
<p>In a generic component, we usually have an additional expectation of
|
||||
<i>exception-neutrality</i>, which means that exceptions thrown by a
|
||||
component's type parameters should be propagated, unchanged, to the
|
||||
component's caller.
|
||||
|
||||
<h2>2 Myths and Superstitions</h2>
|
||||
|
||||
<p>Exception-safety seems straightforward so far: it doesn't constitute
|
||||
anything more than we'd expect from code using more traditional
|
||||
error-handling techniques. It might be worthwhile, however, to examine the
|
||||
term from a psychological viewpoint. Nobody ever spoke of
|
||||
``error-safety'' before C++ had exceptions.
|
||||
|
||||
<p>It's almost as though exceptions are viewed as a <i>mysterious
|
||||
attack</i> on otherwise correct code, from which we must protect ourselves.
|
||||
Needless to say, this doesn't lead to a healthy relationship with error
|
||||
handling! During standardization, a democratic process which requires broad
|
||||
support for changes, I encountered many widely-held superstitions. In order
|
||||
to even begin the discussion of exception-safety in generic components, it
|
||||
may be worthwhile confronting a few of them.
|
||||
|
||||
<p><i>``Interactions between templates and exceptions are not
|
||||
well-understood.''</i> This myth, often heard from those who consider
|
||||
these both new language features, is easily disposed of: there simply are
|
||||
no interactions. A template, once instantiated, works in all respects like
|
||||
an ordinary class or function. A simple way to reason about the behavior of
|
||||
a template with exceptions is to think of how a specific instantiation of
|
||||
that template works. Finally, the genericity of templates should not cause
|
||||
special concern. Although the component's client supplies part of the
|
||||
operation (which may, unless otherwise specified, throw arbitrary
|
||||
exceptions), the same is true of operations using familiar virtual
|
||||
functions or simple function pointers.
|
||||
|
||||
<p><i>``It is well known to be impossible to write an exception-safe
|
||||
generic container.''</i> This claim is often heard with reference to
|
||||
an article by Tom Cargill <a title=
|
||||
"Tom Cargill, ``Exception Handling: A False Sense of Security'', C++ Report, Nov-Dec 1994"
|
||||
href=
|
||||
"#reference4"><sup>[4]</sup></a>
|
||||
in which he explores the problem of exception-safety for a generic stack
|
||||
template. In his article, Cargill raises many useful questions, but
|
||||
unfortunately fails to present a solution to his problem.<a title=
|
||||
"Probably the greatest impediment to a solution in Cargill's case was an unfortunate combination of choices on his part: the interface he chose for his container was incompatible with his particular demands for safety. By changing either one he might have solved the problem."
|
||||
href=
|
||||
"#footnote1"><sup>1</sup></a>
|
||||
He concludes by suggesting that a solution may not be possible.
|
||||
Unfortunately, his article was read by many as ``proof'' of that
|
||||
speculation. Since it was published there have been many examples of
|
||||
exception-safe generic components, among them the C++ standard library
|
||||
containers.
|
||||
|
||||
<p><i>``Dealing with exceptions will slow code down, and templates are
|
||||
used specifically to get the best possible performance.''</i> A good
|
||||
implementation of C++ will not devote a single instruction cycle to dealing
|
||||
with exceptions until one is thrown, and then it can be handled at a speed
|
||||
comparable with that of calling a function <a title=
|
||||
"D. R. Musser, ``Introspective Sorting and Selection Algorithms'', Software-Practice and Experience 27(8):983-993, 1997."
|
||||
href=
|
||||
"#reference7"><sup>[7]</sup></a>.
|
||||
That alone gives programs using exceptions performance equivalent to that
|
||||
of a program which ignores the possibility of errors. Using exceptions can
|
||||
actually result in faster programs than ``traditional'' error
|
||||
handling methods for other reasons. First, a catch block clearly indicates
|
||||
to the compiler which code is devoted to error-handling; it can then be
|
||||
separated from the usual execution path, improving locality of reference.
|
||||
Second, code using ``traditional'' error handling must typically
|
||||
test a return value for errors after every single function call; using
|
||||
exceptions completely eliminates that overhead.
|
||||
|
||||
<p><i>``Exceptions make it more difficult to reason about a program's
|
||||
behavior.''</i> Usually cited in support of this myth is the way
|
||||
``hidden'' execution paths are followed during stack-unwinding.
|
||||
Hidden execution paths are nothing new to any C++ programmer who expects
|
||||
local variables to be destroyed upon returning from a function:
|
||||
|
||||
<blockquote>
|
||||
<pre>ErrorCode f( int& result ) // 1
|
||||
{ // 2
|
||||
X x; // 3
|
||||
ErrorCode err = x.g( result ); // 4
|
||||
if ( err != kNoError ) // 5
|
||||
return err; // 6
|
||||
// ...More code here...
|
||||
return kNoError; // 7
|
||||
}
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>In the example above, there is a ``hidden'' call to
|
||||
<code>X::~X()</code> in lines 6 and 7. Granted, using exceptions, there is
|
||||
no code devoted to error handling visible:
|
||||
|
||||
<blockquote>
|
||||
<pre>int f() // 1
|
||||
{ // 2
|
||||
X x; // 3
|
||||
int result = x.g(); // 4
|
||||
// ...More code here...
|
||||
return result; // 5
|
||||
}
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>For many programmers more familiar with exceptions, the second example
|
||||
is actually more readable and understandable than the first. The
|
||||
``hidden'' code paths include the same calls to destructors of
|
||||
local variables. In addition, they follow a simple pattern which acts
|
||||
<i>exactly</i> as though there were a potential return statement after each
|
||||
function call in case of an exception. Readability is enhanced because the
|
||||
normal path of execution is unobscured by error-handling, and return values
|
||||
are freed up to be used in a natural way.
|
||||
|
||||
<p>There is an even more important way in which exceptions can enhance
|
||||
correctness: by allowing simple class invariants. In the first example, if
|
||||
<code>x</code>'s constructor should need to allocate resources, it has no
|
||||
way to report a failure: in C++, constructors have no return values. The
|
||||
usual result when exceptions are avoided is that classes requiring
|
||||
resources must include a separate initializer function which finishes the
|
||||
job of construction. The programmer can therefore never be sure, when an
|
||||
object of class <code>X</code> is used, whether he is handling a
|
||||
full-fledged <code>X</code> or some abortive attempt to construct one (or
|
||||
worse: someone simply forgot to call the initializer!)
|
||||
|
||||
<h2>3 A contractual basis for exception-safety</h2>
|
||||
|
||||
<p>A non-generic component can be described as exception-safe in isolation,
|
||||
but because of its configurability by client code, exception-safety in a
|
||||
generic component usually depends on a contract between the component and
|
||||
its clients. For example, the designer of a generic component might require
|
||||
that an operation which is used in the component's destructor not throw any
|
||||
exceptions.<a title=
|
||||
" It is usually inadvisable to throw an exception from a destructor in C++, since the destructor may itself be called during the stack-unwinding caused by another exception. If the second exception is allowed to propagate beyond the destructor, the program is immediately terminated."
|
||||
href=
|
||||
"#footnote2"><sup>2</sup></a>
|
||||
The generic component might, in return, provide one of the following
|
||||
guarantees:
|
||||
|
||||
<ul>
|
||||
<li>The <i>basic</i> guarantee: that the invariants of the component are
|
||||
preserved, and no resources are leaked.
|
||||
|
||||
<li>The <i>strong</i> guarantee: that the operation has either completed
|
||||
successfully or thrown an exception, leaving the program state exactly as
|
||||
it was before the operation started.
|
||||
|
||||
<li>The <i>no-throw</i> guarantee: that the operation will not throw an
|
||||
exception.
|
||||
</ul>
|
||||
|
||||
<p>The basic guarantee is a simple minimum standard for exception-safety to
|
||||
which we can hold all components. It says simply that after an exception,
|
||||
the component can still be used as before. Importantly, the preservation of
|
||||
invariants allows the component to be destroyed, potentially as part of
|
||||
stack-unwinding. This guarantee is actually less useful than it might at
|
||||
first appear. If a component has many valid states, after an exception we
|
||||
have no idea what state the component is in|only that the state is valid.
|
||||
The options for recovery in this case are limited: either destruction or
|
||||
resetting the component to some known state before further use. Consider
|
||||
the following example:
|
||||
|
||||
<blockquote>
|
||||
<pre>template <class X>
|
||||
void print_random_sequence()
|
||||
{
|
||||
std::vector<X> v(10); // A vector of 10 items
|
||||
try {
|
||||
// Provides only the <i>basic</i> guarantee
|
||||
v.insert( v.begin(), X() );
|
||||
}
|
||||
catch(...) {} // ignore any exceptions above
|
||||
// print the vector's contents
|
||||
std::cout "(" << v.size() << ") ";
|
||||
std::copy( v.begin(), v.end(),
|
||||
std::ostream_iterator<X>( std::cout, " " ) );
|
||||
}
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>Since all we know about v after an exception is that it is valid, the
|
||||
function is allowed to print any random sequence of <code>X</code>s.<a
|
||||
title=
|
||||
"In practice of course, this function would make an extremely poor random sequence generator!"
|
||||
href=
|
||||
"#footnote3"><sup>3</sup></a>
|
||||
It is ``safe'' in the sense that it is not allowed to crash, but
|
||||
its output may be unpredictable.
|
||||
|
||||
<p>The <i>strong</i> guarantee provides full
|
||||
``commit-or-rollback'' semantics. In the case of C++ standard
|
||||
containers, this means, for example, that if an exception is thrown all
|
||||
iterators remain valid. We also know that the container has exactly the
|
||||
same elements as before the exception was thrown. A transaction that has no
|
||||
effects if it fails has obvious benefits: the program state is simple and
|
||||
predictable in case of an exception. In the C++ standard library, nearly
|
||||
all of the operations on the node-based containers list, set, multiset,
|
||||
map, and multimap provide the <i>strong</i> guarantee.<a title=
|
||||
"It is worth noting that mutating algorithms usually cannot provide the strong guarantee: to roll back a modified element of a range, it must be set back to its previous value using operator=, which itself might throw. In the C++ standard library, there are a few exceptions to this rule, whose rollback behavior consists only of destruction: uninitialized_copy, uninitialized_fill, and uninitialized_fill_n."
|
||||
href=
|
||||
"#footnote4"><sup>4</sup></a>).
|
||||
|
||||
<p>The <i>no-throw</i> guarantee is the strongest of all, and it says that
|
||||
an operation is guaranteed not to throw an exception: it always completes
|
||||
successfully. This guarantee is necessary for most destructors, and indeed
|
||||
the destructors of C++ standard library components are all guaranteed not
|
||||
to throw exceptions. The <i>no-throw</i> guarantee turns out to be
|
||||
important for other reasons, as we shall see.<a title=
|
||||
"All type parameters supplied by clients of the C++ standard library are required not to throw from their destructors. In return, all components of the C++ standard library provide at least the basic guarantee."
|
||||
href=
|
||||
"#footnote5"><sup>5</sup></a>
|
||||
|
||||
<h2>4 Legal Wrangling</h2>
|
||||
|
||||
<p>Inevitably, the contract can get more complicated: a quid pro quo
|
||||
arrangement is possible. Some components in the C++ Standard Library give
|
||||
one guarantee for arbitrary type parameters, but give a stronger guarantee
|
||||
in exchange for additional promises from the client type that no exceptions
|
||||
will be thrown. For example, the standard container operation
|
||||
<code>vector<T>::erase</code> gives the <i>basic</i> guarantee for
|
||||
any <code>T</code>, but for types whose copy constructor and copy
|
||||
assignment operator do not throw, it gives the <i>no-throw</i> guarantee.<a
|
||||
title=
|
||||
"Similar arrangements might have been made in the C++ standard for many of the mutating algorithms, but were never considered due to time constraints on the standardization process."
|
||||
href=
|
||||
"#footnote6"><sup>6</sup></a>
|
||||
|
||||
<h2>5 What level of exception-safety should a component specify?</h2>
|
||||
|
||||
<p>From a client's point-of-view, the strongest possible level of safety
|
||||
would be ideal. Of course, the <i>no-throw</i> guarantee is simply
|
||||
impossible for many operations, but what about the <i>strong</i> guarantee?
|
||||
For example, suppose we wanted atomic behavior for
|
||||
<code>vector<T>::insert</code>. Insertion into the middle of a vector
|
||||
requires copying elements after the insertion point into later positions,
|
||||
to make room for the new element. If copying an element can fail, rolling
|
||||
back the operation would require ``undoing'' the previous
|
||||
copies...which depends on copying again. If copying back should fail (as it
|
||||
likely would), we have failed to meet our guarantee.
|
||||
|
||||
<p>One possible alternative would be to redefine <code>insert</code> to
|
||||
build the new array contents in a fresh piece of memory each time, and only
|
||||
destroy the old contents when that has succeeded. Unfortunately, there is a
|
||||
non-trivial cost if this approach is followed: insertions near the end of a
|
||||
vector which might have previously caused only a few copies would now cause
|
||||
every element to be copied. The <i>basic</i> guarantee is a
|
||||
``natural'' level of safety for this operation, which it can
|
||||
provide without violating its performance guarantees. In fact all of the
|
||||
operations in the library appear to have such a ``natural'' level
|
||||
of safety.
|
||||
|
||||
<p>Because performance requirements were already a well-established part of
|
||||
the draft standard and because performance is a primary goal of the STL,
|
||||
there was no attempt to specify more safety than could be provided within
|
||||
those requirements. Although not all of the library gives the <i>strong</i>
|
||||
guarantee, almost any operation on a standard container which gives the
|
||||
<i>basic</i> guarantee can be made <i>strong</i> using the ``make a
|
||||
new copy'' strategy described above:
|
||||
|
||||
<blockquote>
|
||||
<pre>template <class Container, class BasicOp>
|
||||
void MakeOperationStrong( Container& c, const BasicOp& op )
|
||||
{
|
||||
Container tmp(c); // Copy c
|
||||
op(tmp); // Work on the copy
|
||||
c.swap(tmp); // Cannot fail<a title=
|
||||
"Associative containers whose Compare object might throw an exception when copied cannot use this technique, since the swap function might fail."
|
||||
href=
|
||||
"#footnote7"><sup>7</sup></a>
|
||||
}
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>This technique can be folded into a wrapper class to make a similar
|
||||
container which provides stronger guarantees (and different performance
|
||||
characteristics).<a title=
|
||||
"This suggests another potential use for the oft-wished-for but as yet unseen container traits<> template: automated container selection to meet exceptionsafety constraints."
|
||||
href=
|
||||
"#footnote8"><sup>8</sup></a>
|
||||
|
||||
<h2>6 Should we take everything we can get?</h2>
|
||||
|
||||
<p>By considering a particular implementation, we can hope to discern a
|
||||
natural level of safety. The danger in using this to establish requirements
|
||||
for a component is that the implementation might be restricted. If someone
|
||||
should come up with a more-efficient implementation which we'd like to use,
|
||||
we may find that it's incompatible with our exception-safety requirements.
|
||||
One might expect this to be of no concern in the well-explored domains of
|
||||
data structures and algorithms covered by the STL, but even there, advances
|
||||
are being made. A good example is the recent <i>introsort</i> algorithm <a
|
||||
title=
|
||||
"D. R. Musser, ``Introspective Sorting and Selection Algorithms'', Software-Practice and Experience 27(8):983-993, 1997."
|
||||
href=
|
||||
"#reference6"><sup>[6]</sup></a>,
|
||||
which represents a substantial improvement in worst-case complexity over
|
||||
the well-established <i>quicksort</i>.
|
||||
|
||||
<p>To determine exactly how much to demand of the standard components, I
|
||||
looked at a typical real-world scenario. The chosen test case was a
|
||||
``composite container.'' Such a container, built of two or more
|
||||
standard container components, is not only commonly needed, but serves as a
|
||||
simple representative case for maintaining invariants in larger systems:
|
||||
|
||||
<blockquote>
|
||||
<pre>// SearchableStack - A stack which can be efficiently searched
|
||||
// for any value.
|
||||
template <class T>
|
||||
class SearchableStack
|
||||
{
|
||||
public:
|
||||
void push(const T& t); // O(log n)
|
||||
void pop(); // O(log n)
|
||||
bool contains(const T& t) const; // O(log n)
|
||||
const T& top() const; // O(1)
|
||||
private:
|
||||
std::set<T> set_impl;
|
||||
std::list<std::set<T>::iterator> list_impl;
|
||||
};
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>The idea is that the list acts as a stack of set iterators: every
|
||||
element goes into the set first, and the resulting position is pushed onto
|
||||
the list. The invariant is straightforward: the set and the list should
|
||||
always have the same number of elements, and every element of the set
|
||||
should be referenced by an element of the list. The following
|
||||
implementation of the push function is designed to give the <i>strong</i>
|
||||
guarantee within the natural levels of safety provided by set and list:
|
||||
|
||||
<blockquote>
|
||||
<pre>template <class T> // 1
|
||||
void SearchableStack<T>::push(const T& t) // 2
|
||||
{ // 3
|
||||
set<T>::iterator i = set_impl.insert(t); // 4
|
||||
try // 5
|
||||
{ // 6
|
||||
list_impl.push_back(i); // 7
|
||||
} // 8
|
||||
catch(...) // 9
|
||||
{ // 10
|
||||
set_impl.erase(i); // 11
|
||||
throw; // 12
|
||||
} // 13
|
||||
} // 14
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>What does our code actually require of the library? We need to examine
|
||||
the lines where non-const operations occur:
|
||||
|
||||
<ul>
|
||||
<li>Line 4: if the insertion fails but <code>set_impl</code> is modified
|
||||
in the process, our invariant is violated. We need to be able to rely on
|
||||
the <i>strong</i> guarantee from <code>set<T>::insert</code>.
|
||||
|
||||
<li>Line 7: likewise, if <code>push_back</code> fails, but
|
||||
<code>list_impl</code> is modified in the process, our invariant is
|
||||
violated, so we need to be able to rely on the <i>strong</i> guarantee
|
||||
from list<T>::insert.
|
||||
|
||||
<li>Line 11: here we are ``rolling back'' the insertion on line
|
||||
4. If this operation should fail, we will be unable to restore our
|
||||
invariant. We absolutely depend on the <i>no-throw</i> guarantee from
|
||||
<code>set<T>::erase</code>.<a title=
|
||||
"One might be tempted to surround the erase operation with a try/catch block to reduce the requirements on set<T> and the problems that arise in case of an exception, but in the end that just begs the question. First, erase just failed and in this case there are no viable alternative ways to produce the necessary result. Second and more generally, because of the variability of its type parameters a generic component can seldom be assured that any alternatives will succeed."
|
||||
href=
|
||||
"#footnote9"><sup>9</sup></a>
|
||||
|
||||
<li>Line 11: for the same reasons, we also depend on being able to pass
|
||||
the <code>i</code> to the <code>erase</code> function: we need the
|
||||
<i>no-throw</i> guarantee from the copy constructor of
|
||||
<code>set<T>::iterator</code>.
|
||||
</ul>
|
||||
|
||||
<p>I learned a great deal by approaching the question this way during
|
||||
standardization. First, the guarantee specified for the composite container
|
||||
actually depends on stronger guarantees from its components (the
|
||||
<i>no-throw</i> guarantees in line 11). Also, I took advantage of all of
|
||||
the natural level of safety to implement this simple example. Finally, the
|
||||
analysis revealed a requirement on iterators which I had previously
|
||||
overlooked when operations were considered on their own. The conclusion was
|
||||
that we should provide as much of the natural level of safety as possible.
|
||||
Faster but less-safe implementations could always be provided as extensions
|
||||
to the standard components. <sup><a title=
|
||||
"The prevalent philosophy in the design of STL was that functionality that wasn't essential to all uses should be left out in favor of efficiency, as long as that functionality could be obtained when needed by adapting the base components. This departs from that philosophy, but it would be difficult or impossible to obtain even the basic guarantee by adapting a base component that doesn't already have it."
|
||||
name="#footnote10">10</a></sup>
|
||||
|
||||
<h2>7 Automated testing for exception-safety</h2>
|
||||
|
||||
<p>As part of the standardization process, I produced an exception-safe
|
||||
reference implementation of the STL. Error-handling code is seldom
|
||||
rigorously tested in real life, in part because it is difficult to cause
|
||||
error conditions to occur. It is very common to see error-handling code
|
||||
which crashes the first time it is executed ...in a shipping product! To
|
||||
bolster confidence that the implementation actually worked as advertised, I
|
||||
designed an automated test suite, based on an exhaustive technique due to
|
||||
my colleague Matt Arnold.
|
||||
|
||||
<p>The test program started with the basics: reinforcement and
|
||||
instrumentation, especially of the global operators <code>new</code> and
|
||||
<code>delete</code>.<sup><a title=
|
||||
"An excellent discussion on how to fortify memory subsystems can be found in: Steve Maguire, Writing Solid Code, Microsoft Press, Redmond, WA, 1993, ISBN 1-55615- 551-4."
|
||||
name="#footnote11">11</a></sup>Instances of the components (containers and
|
||||
algorithms) were created, with type parameters chosen to reveal as many
|
||||
potential problems as possible. For example, all type parameters were given
|
||||
a pointer to heap-allocated memory, so that leaking a contained object
|
||||
would be detected as a memory leak.
|
||||
|
||||
<p>Finally, a scheme was designed that could cause an operation to throw an
|
||||
exception at each possible point of failure. At the beginning of every
|
||||
client-supplied operation which is allowed to throw an exception, a call to
|
||||
<code>ThisCanThrow</code> was added. A call to <code>ThisCanThrow</code>
|
||||
also had to be added everywhere that the generic operation being tested
|
||||
might throw an exception, for example in the global operator
|
||||
<code>new</code>, for which an instrumented replacement was supplied.
|
||||
|
||||
<blockquote>
|
||||
<pre>// Use this as a type parameter, e.g. vector<TestClass>
|
||||
struct TestClass
|
||||
{
|
||||
TestClass( int v = 0 )
|
||||
: p( ThisCanThrow(), new int( v ) ) {}
|
||||
TestClass( const TestClass& rhs )
|
||||
: p( ThisCanThrow(), new int( *rhs.p ) ) {}
|
||||
const TestClass& operator=( const TestClass& rhs )
|
||||
{ ThisCanThrow(); *p = *rhs.p; }
|
||||
bool operator==( const TestClass& rhs ) const
|
||||
{ ThisCanThrow(); return *p == *rhs.p; }
|
||||
...etc...
|
||||
~TestClass() { delete p; }
|
||||
};
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p><code>ThisCanThrow</code> simply decrements a ``throw
|
||||
counter'' and, if it has reached zero, throws an exception. Each test
|
||||
takes a form which begins the counter at successively higher values in an
|
||||
outer loop and repeatedly attempts to complete the operation being tested.
|
||||
The result is that the operation throws an exception at each successive
|
||||
step along its execution path that can possibly fail. For example, here is
|
||||
a simplified version of the function used to test the <i>strong</i>
|
||||
guarantee: <a title=
|
||||
"Note that this technique requires that the operation being tested be exception-neutral. If the operation ever tries to recover from an exception and proceed, the throw counter will be negative, and subsequent operations that might fail will not be tested for exception-safety."
|
||||
href=
|
||||
"#footnote12"><sup>12</sup></a>
|
||||
|
||||
<blockquote>
|
||||
<pre>extern int gThrowCounter; // The throw counter
|
||||
void ThisCanThrow()
|
||||
{
|
||||
if (gThrowCounter-- == 0)
|
||||
throw 0;
|
||||
}
|
||||
|
||||
template <class Value, class Operation>
|
||||
void StrongCheck(const Value& v, const Operation& op)
|
||||
{
|
||||
bool succeeded = false;
|
||||
for (long nextThrowCount = 0; !succeeded; ++nextThrowCount)
|
||||
{
|
||||
Value duplicate = v;
|
||||
try
|
||||
{
|
||||
gThrowCounter = nextThrowCount;
|
||||
op( duplicate ); // Try the operation
|
||||
succeeded = true;
|
||||
}
|
||||
catch(...) // Catch all exceptions
|
||||
{
|
||||
bool unchanged = duplicate == v; // Test <i>strong</i> guarantee
|
||||
assert( unchanged );
|
||||
}
|
||||
// Specialize as desired for each container type, to check
|
||||
// integrity. For example, size() == distance(begin(),end())
|
||||
CheckInvariant(v); // Check any invariant
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>Notably, this kind of testing is much easier and less intrusive with a
|
||||
generic component than with non-generics, because testing-specific type
|
||||
parameters can be used without modifying the source code of the component
|
||||
being tested. Also, generic functions like <code>StrongCheck</code> above
|
||||
were instrumental in performing the tests on a wide range of values and
|
||||
operations.
|
||||
|
||||
<h2>8 Further Reading</h2>
|
||||
To my knowledge, there are currently only two descriptions of STL
|
||||
exception-safety available. The original specification <a title=
|
||||
"D. Abrahams, Exception Safety in STLport" href=
|
||||
"#reference2"><sup>[2]</sup></a>
|
||||
for the reference exception-safe implementation of the STL is an informal
|
||||
specification, simple and self-explanatory (also verbose), and uses the
|
||||
<i>basic-</i> and <i>strong-</i>guarantee distinctions outlined in this
|
||||
article. It explicitly forbids leaks, and differs substantively from the
|
||||
final C++ standard in the guarantees it makes, though they are largely
|
||||
identical. I hope to produce an updated version of this document soon.
|
||||
|
||||
<p>The description of exception-safety in the C++ Standard <a title=
|
||||
"International Standard ISO/IEC 14882, Information Technology-Programming Languages-C++, Document Number ISO/IEC 14882-1998"
|
||||
href=
|
||||
"#reference1"><sup>[1]</sup></a>
|
||||
is only slightly more formal, but relies on hard-to-read
|
||||
``standardese'' and an occasionally subtle web of implication.<a
|
||||
title=
|
||||
"The changes to the draft standard which introduced exception-safety were made late in the process, when amendments were likely to be rejected solely on the basis of the number of altered words. Unfortunately, the result compromises clarity somewhat in favor of brevity. Greg Colvin was responsible for the clever language-lawyering needed to minimize the extent of these changes."
|
||||
href=
|
||||
"#footnote13"><sup>13</sup></a>
|
||||
In particular, leaks are not treated directly at all. It does have the
|
||||
advantage that it <i>is</i> the standard.
|
||||
|
||||
<p>The original reference implementation <a title=
|
||||
"B. Fomitchev, Adapted SGI STL Version 1.0, with exception handling code by D. Abrahams"
|
||||
href=
|
||||
"#reference5"><sup>[5]</sup></a>
|
||||
of the exception-safe STL is an adaptation of an old version of the SGI
|
||||
STL, designed for C++ compilers with limited features. Although it is not a
|
||||
complete STL implementation, the code may be easier to read, and it
|
||||
illustrates a useful base-class technique for eliminating
|
||||
exception-handling code in constructors. The full test suite <a title=
|
||||
"D. Abrahams and B. Fomitchev, Exception Handling Test Suite" href=
|
||||
"#reference3"><sup>[3]</sup></a>
|
||||
used to validate the reference implementation has been used successfully to
|
||||
validate all recent versions of the SGI STL, and has been adapted to test
|
||||
one other vendor's implementation (which failed). As noted on the
|
||||
documentation page, it also seems to have the power to reveal hidden
|
||||
compiler bugs, particularly where optimizers interact with
|
||||
exception-handling code.
|
||||
|
||||
<h2>References</h2>
|
||||
|
||||
<ol>
|
||||
<li><a name="reference1">International</a> Standard ISO/IEC 14882,
|
||||
<i>Information Technology-Programming Languages-C++</i>, Document Number
|
||||
ISO/IEC 14882-1998, available from <a href=
|
||||
"http://webstore.ansi.org/ansidocstore/default.asp">http://webstore.ansi.org/ansidocstore/default.asp</a>.
|
||||
|
||||
<li><a name="reference2">D.</a> Abrahams, <i>Exception Safety in
|
||||
STLport</i>, available at <a href=
|
||||
"http://www.stlport.org/doc/exception_safety.html">http://www.stlport.org/doc/exception_safety.html</a>.
|
||||
|
||||
<li><a name="reference3">D.</a> Abrahams and B. Fomitchev, <i>Exception
|
||||
Handling Test Suite</i>, available at <a href=
|
||||
"http://www.stlport.org/doc/eh_testsuite.html">http://www.stlport.org/doc/eh_testsuite.html</a>.
|
||||
|
||||
<li><a name="reference4">Tom</a> Cargill, ``Exception Handling:
|
||||
A False Sense of Security,'' C++ Report, Nov-Dec 1994, also
|
||||
available at <a href=
|
||||
"http://www.awprofessional.com/content/images/020163371x/supplements/Exception_Handling_Article.html">http://www.awprofessional.com/content/images/020163371x/supplements/Exception_Handling_Article.html</a>.
|
||||
|
||||
<li><a name="reference5">B.</a> Fomitchev, <i>Adapted SGI STL Version
|
||||
1.0</i>, with exception handling code by D. Abrahams, available at <a
|
||||
href="http://www.stlport.org">http://www.stlport.org</a>.
|
||||
|
||||
<li><a name="reference6">D.</a> R. Musser, ``Introspective Sorting
|
||||
and Selection Algorithms,'' <i>Software-Practice and Experience</i>
|
||||
27(8):983-993, 1997.
|
||||
|
||||
<li><a name="reference7">Bjarne</a> Stroustrup, <i>The Design And
|
||||
Evolution of C++</i>. Addison Wesley, Reading, MA, 1995, ISBN
|
||||
0-201-54330-3, Section 16.9.1.
|
||||
</ol>
|
||||
|
||||
<h2>Footnotes</h2>
|
||||
|
||||
<p><a name="footnote1">1</a> Probably the greatest impediment to a solution
|
||||
in Cargill's case was an unfortunate combination of choices on his part:
|
||||
the interface he chose for his container was incompatible with his
|
||||
particular demands for safety. By changing either one he might have solved
|
||||
the problem.
|
||||
|
||||
<p><a name="footnote2">2</a> It is usually inadvisable to throw an
|
||||
exception from a destructor in C++, since the destructor may itself be
|
||||
called during the stack-unwinding caused by another exception. If the
|
||||
second exception is allowed to propagate beyond the destructor, the program
|
||||
is immediately terminated.
|
||||
|
||||
<p><a name="footnote3">3</a> In practice of course, this function would
|
||||
make an extremely poor random sequence generator!
|
||||
|
||||
<p><a name="footnote4">4</a> It is worth noting that mutating algorithms
|
||||
usually cannot provide the <i>strong</i> guarantee: to roll back a modified
|
||||
element of a range, it must be set back to its previous value using
|
||||
<code>operator=</code>, which itself might throw. In the C++ standard
|
||||
library, there are a few exceptions to this rule, whose rollback behavior
|
||||
consists only of destruction: <code>uninitialized_copy</code>,
|
||||
<code>uninitialized_fill</code>, and <code>uninitialized_fill_n</code>.
|
||||
|
||||
<p><a name="footnote5">5</a> All type parameters supplied by clients of the
|
||||
C++ standard library are required not to throw from their destructors. In
|
||||
return, all components of the C++ standard library provide at least the
|
||||
<i>basic</i> guarantee.
|
||||
|
||||
<p><a name="footnote6">6</a> Similar arrangements might have been made in
|
||||
the C++ standard for many of the mutating algorithms, but were never
|
||||
considered due to time constraints on the standardization process.
|
||||
|
||||
<p><a name="footnote7">7</a> Associative containers whose
|
||||
<code>Compare</code> object might throw an exception when copied cannot use
|
||||
this technique, since the swap function might fail.
|
||||
|
||||
<p><a name="footnote8">8</a> This suggests another potential use for the
|
||||
oft-wished-for but as yet unseen <code>container_traits<></code>
|
||||
template: automated container selection to meet exception-safety
|
||||
constraints.
|
||||
|
||||
<p><a name="footnote9">9</a> One might be tempted to surround the erase
|
||||
operation with a <code>try</code>/<code>catch</code> block to reduce the
|
||||
requirements on <code>set<T></code> and the problems that arise in
|
||||
case of an exception, but in the end that just begs the question. First,
|
||||
erase just failed and in this case there are no viable alternative ways to
|
||||
produce the necessary result. Second and more generally, because of the
|
||||
variability of its type parameters a generic component can seldom be
|
||||
assured that any alternatives will succeed.
|
||||
|
||||
<p><a name="footnote10">10</a> The prevalent philosophy in the design of
|
||||
STL was that functionality that wasn't essential to all uses should be left
|
||||
out in favor of efficiency, as long as that functionality could be obtained
|
||||
when needed by adapting the base components. This departs from that
|
||||
philosophy, but it would be difficult or impossible to obtain even the
|
||||
<i>basic</i> guarantee by adapting a base component that doesn't already
|
||||
have it.
|
||||
|
||||
<p><a name="footnote11">11</a> An excellent discussion on how to fortify
|
||||
memory subsystems can be found in: Steve Maguire, Writing Solid Code,
|
||||
Microsoft Press, Redmond, WA, 1993, ISBN 1-55615- 551-4.
|
||||
|
||||
<p><a name="footnote12">12</a> Note that this technique requires that the
|
||||
operation being tested be exception-neutral. If the operation ever tries to
|
||||
recover from an exception and proceed, the throw counter will be negative,
|
||||
and subsequent operations that might fail will not be tested for
|
||||
exception-safety.
|
||||
|
||||
<p><a name="footnote13">13</a> The changes to the draft standard which
|
||||
introduced exception-safety were made late in the process, when amendments
|
||||
were likely to be rejected solely on the basis of the number of altered
|
||||
words. Unfortunately, the result compromises clarity somewhat in favor of
|
||||
brevity. Greg Colvin was responsible for the clever language-lawyering
|
||||
needed to minimize the extent of these changes.
|
@ -1,474 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Cygwin (vers 1st April 2002), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=windows-1252">
|
||||
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
|
||||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||||
|
||||
<title>Generic Programming Techniques</title>
|
||||
</head>
|
||||
|
||||
<body bgcolor="#FFFFFF" text="#000000">
|
||||
<img src="../boost.png" alt="boost.png (6897 bytes)" align="center"
|
||||
width="277" height="86">
|
||||
|
||||
<h1>Generic Programming Techniques</h1>
|
||||
|
||||
<p>This is an incomplete survey of some of the generic programming
|
||||
techniques used in the <a href="../index.htm">boost</a> libraries.</p>
|
||||
|
||||
<h2>Table of Contents</h2>
|
||||
|
||||
<ul>
|
||||
<li><a href="#introduction">Introduction</a></li>
|
||||
|
||||
<li><a href="#concept">The Anatomy of a Concept</a></li>
|
||||
|
||||
<li><a href="#traits">Traits</a></li>
|
||||
|
||||
<li><a href="#tag_dispatching">Tag Dispatching</a></li>
|
||||
|
||||
<li><a href="#adaptors">Adaptors</a></li>
|
||||
|
||||
<li><a href="#type_generator">Type Generators</a></li>
|
||||
|
||||
<li><a href="#object_generator">Object Generators</a></li>
|
||||
|
||||
<li><a href="#policy">Policy Classes</a></li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="introduction">Introduction</a></h2>
|
||||
|
||||
<p>Generic programming is about generalizing software components so that
|
||||
they can be easily reused in a wide variety of situations. In C++, class
|
||||
and function templates are particularly effective mechanisms for generic
|
||||
programming because they make the generalization possible without
|
||||
sacrificing efficiency.</p>
|
||||
|
||||
<p>As a simple example of generic programming, we will look at how one
|
||||
might generalize the <tt>memcpy()</tt> function of the C standard
|
||||
library. An implementation of <tt>memcpy()</tt> might look like the
|
||||
following:<br>
|
||||
<br>
|
||||
</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
void* memcpy(void* region1, const void* region2, size_t n)
|
||||
{
|
||||
const char* first = (const char*)region2;
|
||||
const char* last = ((const char*)region2) + n;
|
||||
char* result = (char*)region1;
|
||||
while (first != last)
|
||||
*result++ = *first++;
|
||||
return result;
|
||||
}
|
||||
</pre>
|
||||
</blockquote>
|
||||
The <tt>memcpy()</tt> function is already generalized to some extent by
|
||||
the use of <tt>void*</tt> so that the function can be used to copy arrays
|
||||
of different kinds of data. But what if the data we would like to copy is
|
||||
not in an array? Perhaps it is in a linked list. Can we generalize the
|
||||
notion of copy to any sequence of elements? Looking at the body of
|
||||
<tt>memcpy()</tt>, the function's <b><i>minimal requirements</i></b> are
|
||||
that it needs to <i>traverse</i> through the sequence using some sort
|
||||
of pointer, <i>access</i> elements pointed to, <i>write</i> the elements
|
||||
to the destination, and <i>compare</i> pointers to know when to stop. The
|
||||
C++ standard library groups requirements such as these into
|
||||
<b><i>concepts</i></b>, in this case the <a href=
|
||||
"http://www.sgi.com/tech/stl/InputIterator.html">Input Iterator</a>
|
||||
concept (for <tt>region2</tt>) and the <a href=
|
||||
"http://www.sgi.com/tech/stl/OutputIterator.html">Output Iterator</a>
|
||||
concept (for <tt>region1</tt>).
|
||||
|
||||
<p>If we rewrite the <tt>memcpy()</tt> as a function template, and use
|
||||
the <a href="http://www.sgi.com/tech/stl/InputIterator.html">Input
|
||||
Iterator</a> and <a href=
|
||||
"http://www.sgi.com/tech/stl/OutputIterator.html">Output Iterator</a>
|
||||
concepts to describe the requirements on the template parameters, we can
|
||||
implement a highly reusable <tt>copy()</tt> function in the following
|
||||
way:<br>
|
||||
<br>
|
||||
</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
template <typename InputIterator, typename OutputIterator>
|
||||
OutputIterator
|
||||
copy(InputIterator first, InputIterator last, OutputIterator result)
|
||||
{
|
||||
while (first != last)
|
||||
*result++ = *first++;
|
||||
return result;
|
||||
}
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>Using the generic <tt>copy()</tt> function, we can now copy elements
|
||||
from any kind of sequence, including a linked list that exports iterators
|
||||
such as <tt>std::<a href=
|
||||
"http://www.sgi.com/tech/stl/List.html">list</a></tt>.<br>
|
||||
<br>
|
||||
</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
#include <list>
|
||||
#include <vector>
|
||||
#include <iostream>
|
||||
|
||||
int main()
|
||||
{
|
||||
const int N = 3;
|
||||
std::vector<int> region1(N);
|
||||
std::list<int> region2;
|
||||
|
||||
region2.push_back(1);
|
||||
region2.push_back(0);
|
||||
region2.push_back(3);
|
||||
|
||||
std::copy(region2.begin(), region2.end(), region1.begin());
|
||||
|
||||
for (int i = 0; i < N; ++i)
|
||||
std::cout << region1[i] << " ";
|
||||
std::cout << std::endl;
|
||||
}
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<h2><a name="concept">Anatomy of a Concept</a></h2>
|
||||
A <b><i>concept</i></b> is a set of requirements
|
||||
consisting of valid expressions, associated types, invariants, and
|
||||
complexity guarantees. A type that satisfies the requirements is
|
||||
said to <b><i>model</i></b> the concept. A concept can extend the
|
||||
requirements of another concept, which is called
|
||||
<b><i>refinement</i></b>.
|
||||
|
||||
<ul>
|
||||
<li><a name="valid_expression"><b>Valid Expressions</b></a> are C++
|
||||
expressions which must compile successfully for the objects involved in
|
||||
the expression to be considered <i>models</i> of the concept.</li>
|
||||
|
||||
<li><a name="associated_type"><b>Associated Types</b></a> are types
|
||||
that are related to the modeling type in that they participate in one
|
||||
or more of the valid expressions. Typically associated types can be
|
||||
accessed either through typedefs nested within a class definition for
|
||||
the modeling type, or they are accessed through a <a href=
|
||||
"#traits">traits class</a>.</li>
|
||||
|
||||
<li><b>Invariants</b> are run-time characteristics of the objects that
|
||||
must always be true, that is, the functions involving the objects must
|
||||
preserve these characteristics. The invariants often take the form of
|
||||
pre-conditions and post-conditions.</li>
|
||||
|
||||
<li><b>Complexity Guarantees</b> are maximum limits on how long the
|
||||
execution of one of the valid expressions will take, or how much of
|
||||
various resources its computation will use.</li>
|
||||
</ul>
|
||||
|
||||
<p>The concepts used in the C++ Standard Library are documented at the <a
|
||||
href="http://www.sgi.com/tech/stl/table_of_contents.html">SGI STL
|
||||
site</a>.</p>
|
||||
|
||||
<h2><a name="traits">Traits</a></h2>
|
||||
|
||||
<p>A traits class provides a way of associating information with a
|
||||
compile-time entity (a type, integral constant, or address). For example,
|
||||
the class template <tt><a href=
|
||||
"http://www.sgi.com/tech/stl/iterator_traits.html">std::iterator_traits<T></a></tt>
|
||||
looks something like this:</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
template <class Iterator>
|
||||
struct iterator_traits {
|
||||
typedef ... iterator_category;
|
||||
typedef ... value_type;
|
||||
typedef ... difference_type;
|
||||
typedef ... pointer;
|
||||
typedef ... reference;
|
||||
};
|
||||
</pre>
|
||||
</blockquote>
|
||||
The traits' <tt>value_type</tt> gives generic code the type which the
|
||||
iterator is "pointing at", while the <tt>iterator_category</tt> can be
|
||||
used to select more efficient algorithms depending on the iterator's
|
||||
capabilities.
|
||||
|
||||
<p>A key feature of traits templates is that they're
|
||||
<i>non-intrusive</i>: they allow us to associate information with
|
||||
arbitrary types, including built-in types and types defined in
|
||||
third-party libraries, Normally, traits are specified for a particular
|
||||
type by (partially) specializing the traits template.</p>
|
||||
|
||||
<p>For an in-depth description of <tt>std::iterator_traits</tt>, see <a
|
||||
href="http://www.sgi.com/tech/stl/iterator_traits.html">this page</a>
|
||||
provided by SGI. Another very different expression of the traits idiom in
|
||||
the standard is <tt>std::numeric_limits<T></tt> which provides
|
||||
constants describing the range and capabilities of numeric types.</p>
|
||||
|
||||
<h2><a name="tag_dispatching">Tag Dispatching</a></h2>
|
||||
|
||||
<p>Tag dispatching is a way of using function overloading to
|
||||
dispatch based on properties of a type, and is often used hand in
|
||||
hand with traits classes. A good example of this synergy is the
|
||||
implementation of the <a href=
|
||||
"http://www.sgi.com/tech/stl/advance.html"><tt>std::advance()</tt></a>
|
||||
function in the C++ Standard Library, which increments an iterator
|
||||
<tt>n</tt> times. Depending on the kind of iterator, there are different
|
||||
optimizations that can be applied in the implementation. If the iterator
|
||||
is <a href="http://www.sgi.com/tech/stl/RandomAccessIterator.html">random
|
||||
access</a> (can jump forward and backward arbitrary distances), then the
|
||||
<tt>advance()</tt> function can simply be implemented with <tt>i +=
|
||||
n</tt>, and is very efficient: constant time. Other iterators must be
|
||||
<tt>advance</tt>d in steps, making the operation linear in n. If the
|
||||
iterator is <a href=
|
||||
"http://www.sgi.com/tech/stl/BidirectionalIterator.html">bidirectional</a>,
|
||||
then it makes sense for <tt>n</tt> to be negative, so we must decide
|
||||
whether to increment or decrement the iterator.</p>
|
||||
|
||||
<p>The relation between tag dispatching and traits classes is that the
|
||||
property used for dispatching (in this case the
|
||||
<tt>iterator_category</tt>) is often accessed through a traits class. The
|
||||
main <tt>advance()</tt> function uses the <a href=
|
||||
"http://www.sgi.com/tech/stl/iterator_traits.html"><tt>iterator_traits</tt></a>
|
||||
class to get the <tt>iterator_category</tt>. It then makes a call the the
|
||||
overloaded <tt>advance_dispatch()</tt> function. The appropriate
|
||||
<tt>advance_dispatch()</tt> is selected by the compiler based on whatever
|
||||
type the <tt>iterator_category</tt> resolves to, either <a href=
|
||||
"http://www.sgi.com/tech/stl/input_iterator_tag.html"><tt>input_iterator_tag</tt></a>,
|
||||
<a href=
|
||||
"http://www.sgi.com/tech/stl/bidirectional_iterator_tag.html"><tt>bidirectional_iterator_tag</tt></a>,
|
||||
or <a href=
|
||||
"http://www.sgi.com/tech/stl/random_access_iterator_tag.html"><tt>random_access_iterator_tag</tt></a>.
|
||||
A <b><i>tag</i></b> is simply a class whose only purpose is to convey
|
||||
some property for use in tag dispatching and similar techniques. Refer to
|
||||
<a href="http://www.sgi.com/tech/stl/iterator_tags.html">this page</a>
|
||||
for a more detailed description of iterator tags.</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
namespace std {
|
||||
struct input_iterator_tag { };
|
||||
struct bidirectional_iterator_tag { };
|
||||
struct random_access_iterator_tag { };
|
||||
|
||||
namespace detail {
|
||||
template <class InputIterator, class Distance>
|
||||
void advance_dispatch(InputIterator& i, Distance n, <b>input_iterator_tag</b>) {
|
||||
while (n--) ++i;
|
||||
}
|
||||
|
||||
template <class BidirectionalIterator, class Distance>
|
||||
void advance_dispatch(BidirectionalIterator& i, Distance n,
|
||||
<b>bidirectional_iterator_tag</b>) {
|
||||
if (n >= 0)
|
||||
while (n--) ++i;
|
||||
else
|
||||
while (n++) --i;
|
||||
}
|
||||
|
||||
template <class RandomAccessIterator, class Distance>
|
||||
void advance_dispatch(RandomAccessIterator& i, Distance n,
|
||||
<b>random_access_iterator_tag</b>) {
|
||||
i += n;
|
||||
}
|
||||
}
|
||||
|
||||
template <class InputIterator, class Distance>
|
||||
void advance(InputIterator& i, Distance n) {
|
||||
typename <b>iterator_traits<InputIterator>::iterator_category</b> category;
|
||||
detail::advance_dispatch(i, n, <b>category</b>);
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<h2><a name="adaptors">Adaptors</a></h2>
|
||||
|
||||
<p>An <i>adaptor</i> is a class template which builds on another type or
|
||||
types to provide a new interface or behavioral variant. Examples of
|
||||
standard adaptors are <a href=
|
||||
"http://www.sgi.com/tech/stl/ReverseIterator.html">std::reverse_iterator</a>,
|
||||
which adapts an iterator type by reversing its motion upon
|
||||
increment/decrement, and <a href=
|
||||
"http://www.sgi.com/tech/stl/stack.html">std::stack</a>, which adapts a
|
||||
container to provide a simple stack interface.</p>
|
||||
|
||||
<p>A more comprehensive review of the adaptors in the standard can be
|
||||
found <a href="http://portal.acm.org/citation.cfm?id=249118.249120">
|
||||
here</a>.</p>
|
||||
|
||||
<h2><a name="type_generator">Type Generators</a></h2>
|
||||
|
||||
<p><b>Note:</b> The <i>type generator</i> concept has largely been
|
||||
superseded by the more refined notion of a <a href=
|
||||
"../libs/mpl/doc/refmanual/metafunction.html"><i>metafunction</i></a>. See
|
||||
<i><a href="http://www.boost-consulting.com/mplbook">C++ Template
|
||||
Metaprogramming</a></i> for an in-depth discussion of metafunctions.</p>
|
||||
|
||||
<p>A <i>type generator</i> is a template whose only purpose is to
|
||||
synthesize a new type or types based on its template argument(s)<a href=
|
||||
"#1">[1]</a>. The generated type is usually expressed as a nested typedef
|
||||
named, appropriately <tt>type</tt>. A type generator is usually used to
|
||||
consolidate a complicated type expression into a simple one. This example
|
||||
uses an old version of <tt><a href=
|
||||
"../libs/iterator/doc/iterator_adaptor.html">iterator_adaptor</a></tt>
|
||||
whose design didn't allow derived iterator types. As a result, every
|
||||
adapted iterator had to be a specialization of <tt>iterator_adaptor</tt>
|
||||
itself and generators were a convenient way to produce those types.</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
template <class Predicate, class Iterator,
|
||||
class Value = <i>complicated default</i>,
|
||||
class Reference = <i>complicated default</i>,
|
||||
class Pointer = <i>complicated default</i>,
|
||||
class Category = <i>complicated default</i>,
|
||||
class Distance = <i>complicated default</i>
|
||||
>
|
||||
struct filter_iterator_generator {
|
||||
typedef iterator_adaptor<
|
||||
|
||||
Iterator,filter_iterator_policies<Predicate,Iterator>,
|
||||
Value,Reference,Pointer,Category,Distance> <b>type</b>;
|
||||
};
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>Now, that's complicated, but producing an adapted filter iterator
|
||||
using the generator is much easier. You can usually just write:</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
boost::filter_iterator_generator<my_predicate,my_base_iterator>::type
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<h2><a name="object_generator">Object Generators</a></h2>
|
||||
|
||||
<p>An <i>object generator</i> is a function template whose only purpose
|
||||
is to construct a new object out of its arguments. Think of it as a kind
|
||||
of generic constructor. An object generator may be more useful than a
|
||||
plain constructor when the exact type to be generated is difficult or
|
||||
impossible to express and the result of the generator can be passed
|
||||
directly to a function rather than stored in a variable. Most Boost
|
||||
object generators are named with the prefix "<tt>make_</tt>", after
|
||||
<tt>std::<a href=
|
||||
"http://www.sgi.com/tech/stl/pair.html">make_pair</a>(const T&, const U&)</tt>.</p>
|
||||
|
||||
<p>For example, given:</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
struct widget {
|
||||
void tweak(int);
|
||||
};
|
||||
std::vector<widget *> widget_ptrs;
|
||||
</pre>
|
||||
</blockquote>
|
||||
By chaining two standard object generators, <tt>std::<a href=
|
||||
"http://www.dinkumware.com/htm_cpl/functio2.html#bind2nd">bind2nd</a>()</tt>
|
||||
and <tt>std::<a href=
|
||||
"http://www.dinkumware.com/htm_cpl/functio2.html#mem_fun">mem_fun</a>()</tt>,
|
||||
we can easily tweak all widgets:
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
void tweak_all_widgets1(int arg)
|
||||
{
|
||||
for_each(widget_ptrs.begin(), widget_ptrs.end(),
|
||||
<b>bind2nd</b>(std::<b>mem_fun</b>(&widget::tweak), arg));
|
||||
}
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>Without using object generators the example above would look like
|
||||
this:</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>
|
||||
void tweak_all_widgets2(int arg)
|
||||
{
|
||||
for_each(struct_ptrs.begin(), struct_ptrs.end(),
|
||||
<b>std::binder2nd<std::mem_fun1_t<void, widget, int> ></b>(
|
||||
std::<b>mem_fun1_t<void, widget, int></b>(&widget::tweak), arg));
|
||||
}
|
||||
</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>As expressions get more complicated the need to reduce the verbosity
|
||||
of type specification gets more compelling.</p>
|
||||
|
||||
<h2><a name="policy">Policy Classes</a></h2>
|
||||
|
||||
<p>A policy class is a template parameter used to transmit behavior. An
|
||||
example from the standard library is <tt>std::<a href=
|
||||
"http://www.dinkumware.com/htm_cpl/memory.html#allocator">allocator</a></tt>,
|
||||
which supplies memory management behaviors to standard <a href=
|
||||
"http://www.sgi.com/tech/stl/Container.html">containers</a>.</p>
|
||||
|
||||
<p>Policy classes have been explored in detail by <a href=
|
||||
"http://www.moderncppdesign.com/">Andrei Alexandrescu</a> in <a href=
|
||||
"http://www.informit.com/articles/article.asp?p=167842">this chapter</a>
|
||||
of his book, <i>Modern C++ Design</i>. He writes:</p>
|
||||
|
||||
<blockquote>
|
||||
<p>In brief, policy-based class design fosters assembling a class with
|
||||
complex behavior out of many little classes (called policies), each of
|
||||
which takes care of only one behavioral or structural aspect. As the
|
||||
name suggests, a policy establishes an interface pertaining to a
|
||||
specific issue. You can implement policies in various ways as long as
|
||||
you respect the policy interface.</p>
|
||||
|
||||
<p>Because you can mix and match policies, you can achieve a
|
||||
combinatorial set of behaviors by using a small core of elementary
|
||||
components.</p>
|
||||
</blockquote>
|
||||
|
||||
<p>Andrei's description of policy classes suggests that their power is
|
||||
derived from granularity and orthogonality. Less-granular policy
|
||||
interfaces have been shown to work well in practice, though. <a href=
|
||||
"http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/utility/Attic/iterator_adaptors.pdf">
|
||||
This paper</a> describes an old version of <tt><a href=
|
||||
"../libs/iterator/doc/iterator_adaptor.html">iterator_adaptor</a></tt>
|
||||
that used non-orthogonal policies. There is also precedent in the
|
||||
standard library: <tt><a href=
|
||||
"http://www.dinkumware.com/htm_cpl/string2.html#char_traits">std::char_traits</a></tt>,
|
||||
despite its name, acts as a policies class that determines the behaviors
|
||||
of <a href=
|
||||
"http://www.dinkumware.com/htm_cpl/string2.html#basic_string">std::basic_string</a>.</p>
|
||||
|
||||
<h2>Notes</h2>
|
||||
<a name="1">[1]</a> Type generators are sometimes viewed as a workaround
|
||||
for the lack of ``templated typedefs'' in C++.
|
||||
<hr>
|
||||
|
||||
<p>Revised
|
||||
<!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %b %Y" startspan -->18
|
||||
August 2004<!--webbot bot="Timestamp" endspan i-checksum="14885" -->
|
||||
</p>
|
||||
|
||||
<p>© Copyright David Abrahams 2001. Permission to copy, use, modify,
|
||||
sell and distribute this document is granted provided this copyright
|
||||
notice appears in all copies. This document is provided "as is" without
|
||||
express or implied warranty, and with no claim as to its suitability for
|
||||
any purpose.
|
||||
<!-- LocalWords: HTML html charset gif alt htm struct SGI namespace std libs
|
||||
-->
|
||||
|
||||
<!-- LocalWords: InputIterator BidirectionalIterator RandomAccessIterator pdf
|
||||
-->
|
||||
|
||||
<!-- LocalWords: typename Alexandrescu templated Andrei's Abrahams memcpy int
|
||||
-->
|
||||
<!-- LocalWords: const OutputIterator iostream pre cpl
|
||||
-->
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
|
@ -5,8 +5,8 @@
|
||||
.. This file contains all the definitions that need to be updated
|
||||
.. for each new release of Boost.
|
||||
|
||||
.. |boost-version-number| replace:: 1.34.1
|
||||
.. |boost_ver| replace:: ``boost_1_34_1``
|
||||
.. |boost_ver-bold| replace:: **boost_1_34_1**
|
||||
.. |boost-version-number| replace:: 1.35.0
|
||||
.. |boost_ver| replace:: ``boost_1_35_0``
|
||||
.. |boost_ver-bold| replace:: **boost_1_35_0**
|
||||
|
||||
.. _sf-download: http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041
|
@ -63,12 +63,12 @@
|
||||
<p>The most reliable way to get a copy of Boost is to download a
|
||||
distribution from <a class="reference external" href="http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041">SourceForge</a>:</p>
|
||||
<ol class="arabic">
|
||||
<li><p class="first">Download <a class="reference external" href="http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041"><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt><tt class="docutils literal"><span class="pre">.tar.bz2</span></tt></a>.</p>
|
||||
<li><p class="first">Download <a class="reference external" href="http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041"><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt><tt class="docutils literal"><span class="pre">.tar.bz2</span></tt></a>.</p>
|
||||
</li>
|
||||
<li><p class="first">In the directory where you want to put the Boost installation,
|
||||
execute</p>
|
||||
<pre class="literal-block">
|
||||
tar --bzip2 -xf <em>/path/to/</em><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt>.tar.bz2
|
||||
tar --bzip2 -xf <em>/path/to/</em><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt>.tar.bz2
|
||||
</pre>
|
||||
</li>
|
||||
</ol>
|
||||
@ -91,7 +91,7 @@ from <a class="reference external" href="http://sourceforge.net/project/showfile
|
||||
<h1><a class="toc-backref" href="#id19">2 The Boost Distribution</a></h1>
|
||||
<p>This is a sketch of the resulting directory structure:</p>
|
||||
<pre class="literal-block">
|
||||
<strong>boost_1_34_1</strong><strong>/</strong> .................<em>The “boost root directory”</em>
|
||||
<strong>boost_1_35_0</strong><strong>/</strong> .................<em>The “boost root directory”</em>
|
||||
<strong>index.htm</strong> .........<em>A copy of www.boost.org starts here</em>
|
||||
<strong>boost</strong><strong>/</strong> .........................<em>All Boost Header files</em>
|
||||
<tt class="docutils literal"> </tt>
|
||||
@ -136,7 +136,7 @@ anything you can use in these directories.</p>
|
||||
</div>
|
||||
<p>It's important to note the following:</p>
|
||||
<ol class="arabic" id="boost-root-directory">
|
||||
<li><p class="first">The path to the <strong>boost root directory</strong> (often <tt class="docutils literal"><span class="pre">/usr/local/</span></tt><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt>) is
|
||||
<li><p class="first">The path to the <strong>boost root directory</strong> (often <tt class="docutils literal"><span class="pre">/usr/local/</span></tt><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt>) is
|
||||
sometimes referred to as <tt class="docutils literal"><span class="pre">$BOOST_ROOT</span></tt> in documentation and
|
||||
mailing lists .</p>
|
||||
</li>
|
||||
@ -230,7 +230,7 @@ int main()
|
||||
<p>Now, in the directory where you saved <tt class="docutils literal"><span class="pre">example.cpp</span></tt>, issue the
|
||||
following command:</p>
|
||||
<pre class="literal-block">
|
||||
c++ -I <em>path/to/</em><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt> example.cpp -o example
|
||||
c++ -I <em>path/to/</em><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt> example.cpp -o example
|
||||
</pre>
|
||||
<p>To test the result, type:</p>
|
||||
<pre class="literal-block">
|
||||
@ -261,7 +261,7 @@ you'll need to acquire library binaries.</p>
|
||||
<p>Issue the following commands in the shell (don't type <tt class="docutils literal"><span class="pre">$</span></tt>; that
|
||||
represents the shell's prompt):</p>
|
||||
<pre class="literal-block">
|
||||
<strong>$</strong> cd <em>path/to/</em><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt>
|
||||
<strong>$</strong> cd <em>path/to/</em><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt>
|
||||
<strong>$</strong> ./configure --help
|
||||
</pre>
|
||||
<p>Select your configuration options and invoke <tt class="docutils literal"><span class="pre">./configure</span></tt> again
|
||||
@ -425,7 +425,7 @@ bjam <strong>--build-dir=</strong><a class="reference internal" href="#id10"><em
|
||||
</pre>
|
||||
<p>For example, your session might look like this:</p>
|
||||
<pre class="literal-block">
|
||||
$ cd ~/<tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt>
|
||||
$ cd ~/<tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt>
|
||||
$ bjam <strong>--build-dir=</strong>/tmp/build-boost <strong>--toolset=</strong>gcc stage
|
||||
</pre>
|
||||
<!-- Copyright David Abrahams 2006. Distributed under the Boost -->
|
||||
@ -533,15 +533,15 @@ project.</li>
|
||||
<ol class="upperalpha">
|
||||
<li><p class="first">You can specify the full path to each library:</p>
|
||||
<pre class="literal-block">
|
||||
$ c++ -I <em>path/to/</em><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt> example.cpp -o example <strong>\</strong>
|
||||
<strong>~/boost/lib/libboost_regex-gcc34-mt-d-1_34.a</strong>
|
||||
$ c++ -I <em>path/to/</em><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt> example.cpp -o example <strong>\</strong>
|
||||
<strong>~/boost/lib/libboost_regex-gcc34-mt-d-1_35.a</strong>
|
||||
</pre>
|
||||
</li>
|
||||
<li><p class="first">You can separately specify a directory to search (with <tt class="docutils literal"><span class="pre">-L</span></tt><em>directory</em>) and a library name to search for (with <tt class="docutils literal"><span class="pre">-l</span></tt><em>library</em>,<a class="footnote-reference" href="#lowercase-l" id="id12"><sup>2</sup></a> dropping the filename's leading <tt class="docutils literal"><span class="pre">lib</span></tt> and trailing
|
||||
suffix (<tt class="docutils literal"><span class="pre">.a</span></tt> in this case):</p>
|
||||
<pre class="literal-block">
|
||||
$ c++ -I <em>path/to/</em><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt> example.cpp -o example <strong>\</strong>
|
||||
<strong>-L~/boost/lib/ -lboost_regex-gcc34-mt-d-1_34</strong>
|
||||
$ c++ -I <em>path/to/</em><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt> example.cpp -o example <strong>\</strong>
|
||||
<strong>-L~/boost/lib/ -lboost_regex-gcc34-mt-d-1_35</strong>
|
||||
</pre>
|
||||
<p>As you can see, this method is just as terse as method A for one
|
||||
library; it <em>really</em> pays off when you're using multiple
|
||||
|
@ -153,7 +153,7 @@ A. You can specify the full path to each library:
|
||||
.. parsed-literal::
|
||||
|
||||
$ c++ -I |root| example.cpp -o example **\\**
|
||||
**~/boost/lib/libboost_regex-gcc34-mt-d-1_34.a**
|
||||
**~/boost/lib/libboost_regex-gcc34-mt-d-1_35.a**
|
||||
|
||||
B. You can separately specify a directory to search (with ``-L``\
|
||||
*directory*) and a library name to search for (with ``-l``\
|
||||
@ -163,7 +163,7 @@ B. You can separately specify a directory to search (with ``-L``\
|
||||
.. parsed-literal::
|
||||
|
||||
$ c++ -I |root| example.cpp -o example **\\**
|
||||
**-L~/boost/lib/ -lboost_regex-gcc34-mt-d-1_34**
|
||||
**-L~/boost/lib/ -lboost_regex-gcc34-mt-d-1_35**
|
||||
|
||||
As you can see, this method is just as terse as method A for one
|
||||
library; it *really* pays off when you're using multiple
|
||||
|
@ -26,40 +26,40 @@ not supported—they may or may not work.</p>
|
||||
<div class="contents topic" id="index">
|
||||
<p class="topic-title first">Index</p>
|
||||
<ul class="auto-toc simple">
|
||||
<li><a class="reference internal" href="#get-boost" id="id23">1 Get Boost</a></li>
|
||||
<li><a class="reference internal" href="#the-boost-distribution" id="id24">2 The Boost Distribution</a></li>
|
||||
<li><a class="reference internal" href="#header-only-libraries" id="id25">3 Header-Only Libraries</a></li>
|
||||
<li><a class="reference internal" href="#build-a-simple-program-using-boost" id="id26">4 Build a Simple Program Using Boost</a><ul class="auto-toc">
|
||||
<li><a class="reference internal" href="#build-from-the-visual-studio-ide" id="id27">4.1 Build From the Visual Studio IDE</a></li>
|
||||
<li><a class="reference internal" href="#or-build-from-the-command-prompt" id="id28">4.2 Or, Build From the Command Prompt</a></li>
|
||||
<li><a class="reference internal" href="#errors-and-warnings" id="id29">4.3 Errors and Warnings</a></li>
|
||||
<li><a class="reference internal" href="#get-boost" id="id24">1 Get Boost</a></li>
|
||||
<li><a class="reference internal" href="#the-boost-distribution" id="id25">2 The Boost Distribution</a></li>
|
||||
<li><a class="reference internal" href="#header-only-libraries" id="id26">3 Header-Only Libraries</a></li>
|
||||
<li><a class="reference internal" href="#build-a-simple-program-using-boost" id="id27">4 Build a Simple Program Using Boost</a><ul class="auto-toc">
|
||||
<li><a class="reference internal" href="#build-from-the-visual-studio-ide" id="id28">4.1 Build From the Visual Studio IDE</a></li>
|
||||
<li><a class="reference internal" href="#or-build-from-the-command-prompt" id="id29">4.2 Or, Build From the Command Prompt</a></li>
|
||||
<li><a class="reference internal" href="#errors-and-warnings" id="id30">4.3 Errors and Warnings</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#prepare-to-use-a-boost-library-binary" id="id30">5 Prepare to Use a Boost Library Binary</a><ul class="auto-toc">
|
||||
<li><a class="reference internal" href="#install-visual-studio-2005-or-net-2003-binaries" id="id31">5.1 Install Visual Studio (2005 or .NET 2003) Binaries</a></li>
|
||||
<li><a class="reference internal" href="#or-build-binaries-from-source" id="id32">5.2 Or, Build Binaries From Source</a><ul class="auto-toc">
|
||||
<li><a class="reference internal" href="#get-bjam" id="id33">5.2.1 Get <tt class="docutils literal"><span class="pre">bjam</span></tt></a></li>
|
||||
<li><a class="reference internal" href="#identify-your-toolset" id="id34">5.2.2 Identify Your Toolset</a></li>
|
||||
<li><a class="reference internal" href="#select-a-build-directory" id="id35">5.2.3 Select a Build Directory</a></li>
|
||||
<li><a class="reference internal" href="#invoke-bjam" id="id36">5.2.4 Invoke <tt class="docutils literal"><span class="pre">bjam</span></tt></a></li>
|
||||
<li><a class="reference internal" href="#prepare-to-use-a-boost-library-binary" id="id31">5 Prepare to Use a Boost Library Binary</a><ul class="auto-toc">
|
||||
<li><a class="reference internal" href="#install-visual-studio-2005-or-net-2003-binaries" id="id32">5.1 Install Visual Studio (2005 or .NET 2003) Binaries</a></li>
|
||||
<li><a class="reference internal" href="#or-build-binaries-from-source" id="id33">5.2 Or, Build Binaries From Source</a><ul class="auto-toc">
|
||||
<li><a class="reference internal" href="#get-bjam" id="id34">5.2.1 Get <tt class="docutils literal"><span class="pre">bjam</span></tt></a></li>
|
||||
<li><a class="reference internal" href="#identify-your-toolset" id="id35">5.2.2 Identify Your Toolset</a></li>
|
||||
<li><a class="reference internal" href="#select-a-build-directory" id="id36">5.2.3 Select a Build Directory</a></li>
|
||||
<li><a class="reference internal" href="#invoke-bjam" id="id37">5.2.4 Invoke <tt class="docutils literal"><span class="pre">bjam</span></tt></a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#expected-build-output" id="id37">5.3 Expected Build Output</a></li>
|
||||
<li><a class="reference internal" href="#in-case-of-build-errors" id="id38">5.4 In Case of Build Errors</a></li>
|
||||
<li><a class="reference internal" href="#expected-build-output" id="id38">5.3 Expected Build Output</a></li>
|
||||
<li><a class="reference internal" href="#in-case-of-build-errors" id="id39">5.4 In Case of Build Errors</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#link-your-program-to-a-boost-library" id="id39">6 Link Your Program to a Boost Library</a><ul class="auto-toc">
|
||||
<li><a class="reference internal" href="#link-from-within-the-visual-studio-ide" id="id40">6.1 Link From Within the Visual Studio IDE</a></li>
|
||||
<li><a class="reference internal" href="#or-link-from-the-command-prompt" id="id41">6.2 Or, Link From the Command Prompt</a></li>
|
||||
<li><a class="reference internal" href="#library-naming" id="id42">6.3 Library Naming</a></li>
|
||||
<li><a class="reference internal" href="#test-your-program" id="id43">6.4 Test Your Program</a></li>
|
||||
<li><a class="reference internal" href="#link-your-program-to-a-boost-library" id="id40">6 Link Your Program to a Boost Library</a><ul class="auto-toc">
|
||||
<li><a class="reference internal" href="#link-from-within-the-visual-studio-ide" id="id41">6.1 Link From Within the Visual Studio IDE</a></li>
|
||||
<li><a class="reference internal" href="#or-link-from-the-command-prompt" id="id42">6.2 Or, Link From the Command Prompt</a></li>
|
||||
<li><a class="reference internal" href="#library-naming" id="id43">6.3 Library Naming</a></li>
|
||||
<li><a class="reference internal" href="#test-your-program" id="id44">6.4 Test Your Program</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#conclusion-and-further-resources" id="id44">7 Conclusion and Further Resources</a></li>
|
||||
<li><a class="reference internal" href="#conclusion-and-further-resources" id="id45">7 Conclusion and Further Resources</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="get-boost">
|
||||
<h1><a class="toc-backref" href="#id23">1 Get Boost</a></h1>
|
||||
<h1><a class="toc-backref" href="#id24">1 Get Boost</a></h1>
|
||||
<p>The easiest way to get a copy of Boost is to use the <a class="reference external" href="http://www.boost-consulting.com/download/windows">installer</a>
|
||||
provided by <a class="reference external" href="http://www.boost-consulting.com">Boost Consulting</a>. We especially recommend this
|
||||
method if you use Microsoft Visual Studio .NET 2003 or Microsoft
|
||||
@ -69,17 +69,17 @@ them yourself. To complete this tutorial, you'll need to at least
|
||||
install the <a class="reference external" href="../../libs/regex/index.html">Boost.Regex</a> binaries when given the option.</p>
|
||||
<p>If you're using an earlier version of Visual Studio or some other
|
||||
compiler, or if you prefer to build everything yourself, you can
|
||||
download <a class="reference external" href="http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041"><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt><tt class="docutils literal"><span class="pre">.exe</span></tt></a> and run it to install a complete Boost
|
||||
download <a class="reference external" href="http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041"><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt><tt class="docutils literal"><span class="pre">.exe</span></tt></a> and run it to install a complete Boost
|
||||
distribution.<a class="footnote-reference" href="#zip" id="id2"><sup>1</sup></a></p>
|
||||
<!-- Copyright David Abrahams 2006. Distributed under the Boost -->
|
||||
<!-- Software License, Version 1.0. (See accompanying -->
|
||||
<!-- file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) -->
|
||||
</div>
|
||||
<div class="section" id="the-boost-distribution">
|
||||
<h1><a class="toc-backref" href="#id24">2 The Boost Distribution</a></h1>
|
||||
<h1><a class="toc-backref" href="#id25">2 The Boost Distribution</a></h1>
|
||||
<p>This is a sketch of the resulting directory structure:</p>
|
||||
<pre class="literal-block">
|
||||
<strong>boost_1_34_1</strong><strong>\</strong> .................<em>The “boost root directory”</em>
|
||||
<strong>boost_1_35_0</strong><strong>\</strong> .................<em>The “boost root directory”</em>
|
||||
<strong>index.htm</strong> .........<em>A copy of www.boost.org starts here</em>
|
||||
<strong>boost</strong><strong>\</strong> .........................<em>All Boost Header files</em>
|
||||
<strong>lib</strong><strong>\</strong> .....................<em>precompiled library binaries</em>
|
||||
@ -124,7 +124,7 @@ anything you can use in these directories.</p>
|
||||
</div>
|
||||
<p>It's important to note the following:</p>
|
||||
<ol class="arabic" id="boost-root-directory">
|
||||
<li><p class="first">The path to the <strong>boost root directory</strong> (often <tt class="docutils literal"><span class="pre">C:\Program</span> <span class="pre">Files\boost\</span></tt><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt>) is
|
||||
<li><p class="first">The path to the <strong>boost root directory</strong> (often <tt class="docutils literal"><span class="pre">C:\Program</span> <span class="pre">Files\boost\</span></tt><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt>) is
|
||||
sometimes referred to as <tt class="docutils literal"><span class="pre">$BOOST_ROOT</span></tt> in documentation and
|
||||
mailing lists .</p>
|
||||
</li>
|
||||
@ -159,7 +159,7 @@ contains a subset of the Boost documentation. Start with
|
||||
<!-- file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) -->
|
||||
</div>
|
||||
<div class="section" id="header-only-libraries">
|
||||
<h1><a class="toc-backref" href="#id25">3 Header-Only Libraries</a></h1>
|
||||
<h1><a class="toc-backref" href="#id26">3 Header-Only Libraries</a></h1>
|
||||
<p>The first thing many people want to know is, “how do I build
|
||||
Boost?” The good news is that often, there's nothing to build.</p>
|
||||
<div class="admonition-nothing-to-build admonition">
|
||||
@ -199,7 +199,7 @@ use</strong>.</li>
|
||||
<!-- file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) -->
|
||||
</div>
|
||||
<div class="section" id="build-a-simple-program-using-boost">
|
||||
<h1><a class="toc-backref" href="#id26">4 Build a Simple Program Using Boost</a></h1>
|
||||
<h1><a class="toc-backref" href="#id27">4 Build a Simple Program Using Boost</a></h1>
|
||||
<p>To keep things simple, let's start by using a header-only library.
|
||||
The following program reads a sequence of integers from standard
|
||||
input, uses Boost.Lambda to multiply each number by three, and
|
||||
@ -248,14 +248,14 @@ cd <em>path</em>\<em>to</em>\<em>some</em>\<em>directory</em>
|
||||
</pre>
|
||||
<p>followed by Return. For example,</p>
|
||||
<pre class="literal-block">
|
||||
cd <tt class="docutils literal"><span class="pre">C:\Program</span> <span class="pre">Files\boost\</span></tt><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt>
|
||||
cd <tt class="docutils literal"><span class="pre">C:\Program</span> <span class="pre">Files\boost\</span></tt><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt>
|
||||
</pre>
|
||||
<p class="last">Long commands can be continued across several lines by typing a
|
||||
caret (<tt class="docutils literal"><span class="pre">^</span></tt>) at the end of all but the last line. Some examples
|
||||
on this page use that technique to save horizontal space.</p>
|
||||
</div>
|
||||
<div class="section" id="build-from-the-visual-studio-ide">
|
||||
<span id="vs-header-only"></span><h2><a class="toc-backref" href="#id27">4.1 Build From the Visual Studio IDE</a></h2>
|
||||
<span id="vs-header-only"></span><h2><a class="toc-backref" href="#id28">4.1 Build From the Visual Studio IDE</a></h2>
|
||||
<ul>
|
||||
<li><p class="first">From Visual Studio's <em>File</em> menu, select <em>New</em> > <em>Project…</em></p>
|
||||
</li>
|
||||
@ -273,7 +273,7 @@ select <em>Properties</em> from the resulting pop-up menu</p>
|
||||
<li><p class="first">In <em>Configuration Properties</em> > <em>C/C++</em> > <em>General</em> > <em>Additional Include
|
||||
Directories</em>, enter the path to the Boost root directory, for example</p>
|
||||
<blockquote>
|
||||
<p><tt class="docutils literal"><span class="pre">C:\Program</span> <span class="pre">Files\boost\</span></tt><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt></p>
|
||||
<p><tt class="docutils literal"><span class="pre">C:\Program</span> <span class="pre">Files\boost\</span></tt><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt></p>
|
||||
</blockquote>
|
||||
</li>
|
||||
<li><p class="first">In <em>Configuration Properties</em> > <em>C/C++</em> > <em>Precompiled Headers</em>, change
|
||||
@ -296,7 +296,7 @@ Return key.</p>
|
||||
<p><a class="reference internal" href="#errors-and-warnings"><em>skip to the next step</em></a></p>
|
||||
</div>
|
||||
<div class="section" id="or-build-from-the-command-prompt">
|
||||
<h2><a class="toc-backref" href="#id28">4.2 Or, Build From the Command Prompt</a></h2>
|
||||
<h2><a class="toc-backref" href="#id29">4.2 Or, Build From the Command Prompt</a></h2>
|
||||
<p>From your computer's <em>Start</em> menu, if you are a Visual
|
||||
Studio 2005 user, select</p>
|
||||
<blockquote>
|
||||
@ -311,7 +311,7 @@ Visual Studio compiler. In that window, set the <a class="reference internal" h
|
||||
directory</a> to a suitable location for creating some temporary
|
||||
files and type the following command followed by the Return key:</p>
|
||||
<pre class="literal-block">
|
||||
cl /EHsc /I <em>path\to\</em><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt> <em>path</em>\<em>to</em>\example.cpp
|
||||
cl /EHsc /I <em>path\to\</em><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt> <em>path</em>\<em>to</em>\example.cpp
|
||||
</pre>
|
||||
<p>To test the result, type:</p>
|
||||
<pre class="literal-block">
|
||||
@ -322,7 +322,7 @@ echo 1 2 3 | example
|
||||
<!-- file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) -->
|
||||
</div>
|
||||
<div class="section" id="errors-and-warnings">
|
||||
<h2><a class="toc-backref" href="#id29">4.3 Errors and Warnings</a></h2>
|
||||
<h2><a class="toc-backref" href="#id30">4.3 Errors and Warnings</a></h2>
|
||||
<p>Don't be alarmed if you see compiler warnings originating in Boost
|
||||
headers. We try to eliminate them, but doing so isn't always
|
||||
practical.<a class="footnote-reference" href="#warnings" id="id7"><sup>5</sup></a> <strong>Errors are another matter</strong>. If you're
|
||||
@ -335,21 +335,21 @@ correctly identified the <a class="reference internal" href="#boost-root-directo
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="prepare-to-use-a-boost-library-binary">
|
||||
<h1><a class="toc-backref" href="#id30">5 Prepare to Use a Boost Library Binary</a></h1>
|
||||
<h1><a class="toc-backref" href="#id31">5 Prepare to Use a Boost Library Binary</a></h1>
|
||||
<p>If you want to use any of the separately-compiled Boost libraries,
|
||||
you'll need to acquire library binaries.</p>
|
||||
<div class="section" id="install-visual-studio-2005-or-net-2003-binaries">
|
||||
<h2><a class="toc-backref" href="#id31">5.1 Install Visual Studio (2005 or .NET 2003) Binaries</a></h2>
|
||||
<h2><a class="toc-backref" href="#id32">5.1 Install Visual Studio (2005 or .NET 2003) Binaries</a></h2>
|
||||
<p>The <a class="reference external" href="http://www.boost-consulting.com/download/windows">installer</a> supplied by Boost Consulting will download and
|
||||
install pre-compiled binaries into the <tt class="docutils literal"><span class="pre">lib\</span></tt> subdirectory of the
|
||||
boost root, typically <tt class="docutils literal"><span class="pre">C:\Program</span> <span class="pre">Files\boost\</span></tt><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt><tt class="docutils literal"><span class="pre">\lib\</span></tt>. If you installed
|
||||
boost root, typically <tt class="docutils literal"><span class="pre">C:\Program</span> <span class="pre">Files\boost\</span></tt><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt><tt class="docutils literal"><span class="pre">\lib\</span></tt>. If you installed
|
||||
all variants of the <a class="reference external" href="../../libs/regex/index.html">Boost.Regex</a> binary, you're done with this
|
||||
step. Otherwise, please run the installer again and install them
|
||||
now.</p>
|
||||
<p><a class="reference internal" href="#link-your-program-to-a-boost-library"><em>skip to the next step</em></a></p>
|
||||
</div>
|
||||
<div class="section" id="or-build-binaries-from-source">
|
||||
<h2><a class="toc-backref" href="#id32">5.2 Or, Build Binaries From Source</a></h2>
|
||||
<h2><a class="toc-backref" href="#id33">5.2 Or, Build Binaries From Source</a></h2>
|
||||
<p>If you're using an earlier version of Visual C++, or a compiler
|
||||
from another vendor, you'll need to use <a class="reference external" href="../../tools/build/index.html">Boost.Build</a> to create your
|
||||
own binaries.</p>
|
||||
@ -361,7 +361,7 @@ installing software. To use it, you'll need an executable called
|
||||
<tt class="docutils literal"><span class="pre">bjam</span></tt>.</p>
|
||||
<!-- .. _Boost.Jam documentation: Boost.Jam_ -->
|
||||
<div class="section" id="get-bjam">
|
||||
<h3><a class="toc-backref" href="#id33">5.2.1 Get <tt class="docutils literal"><span class="pre">bjam</span></tt></a></h3>
|
||||
<h3><a class="toc-backref" href="#id34">5.2.1 Get <tt class="docutils literal"><span class="pre">bjam</span></tt></a></h3>
|
||||
<p><tt class="docutils literal"><span class="pre">bjam</span></tt> is the <a class="reference internal" href="#command-line-tool">command-line tool</a> that drives the Boost Build
|
||||
system. To build Boost binaries, you'll invoke <tt class="docutils literal"><span class="pre">bjam</span></tt> from the
|
||||
Boost root.</p>
|
||||
@ -370,7 +370,7 @@ Alternatively, you can build <tt class="docutils literal"><span class="pre">bjam
|
||||
instructions</a>.</p>
|
||||
</div>
|
||||
<div class="section" id="identify-your-toolset">
|
||||
<span id="toolset-name"></span><span id="toolset"></span><h3><a class="toc-backref" href="#id34">5.2.2 Identify Your Toolset</a></h3>
|
||||
<span id="toolset-name"></span><span id="toolset"></span><h3><a class="toc-backref" href="#id35">5.2.2 Identify Your Toolset</a></h3>
|
||||
<p>First, find the toolset corresponding to your compiler in the
|
||||
following table.</p>
|
||||
<div class="note">
|
||||
@ -475,7 +475,7 @@ are using the msvc or gcc toolsets, which have special version
|
||||
detection code) or <a class="reference internal" href="#auto-linking">auto-linking</a> will fail.</p>
|
||||
</div>
|
||||
<div class="section" id="select-a-build-directory">
|
||||
<span id="id12"></span><span id="build-directory"></span><h3><a class="toc-backref" href="#id35">5.2.3 Select a Build Directory</a></h3>
|
||||
<span id="id12"></span><span id="build-directory"></span><h3><a class="toc-backref" href="#id36">5.2.3 Select a Build Directory</a></h3>
|
||||
<p><a class="reference external" href="../../tools/build/index.html">Boost.Build</a> will place all intermediate files it generates while
|
||||
building into the <strong>build directory</strong>. If your Boost root
|
||||
directory is writable, this step isn't strictly necessary: by
|
||||
@ -483,7 +483,7 @@ default Boost.Build will create a <tt class="docutils literal"><span class="pre"
|
||||
purpose in your current working directory.</p>
|
||||
</div>
|
||||
<div class="section" id="invoke-bjam">
|
||||
<h3><a class="toc-backref" href="#id36">5.2.4 Invoke <tt class="docutils literal"><span class="pre">bjam</span></tt></a></h3>
|
||||
<h3><a class="toc-backref" href="#id37">5.2.4 Invoke <tt class="docutils literal"><span class="pre">bjam</span></tt></a></h3>
|
||||
<p>Change your current directory to the Boost root directory and
|
||||
invoke <tt class="docutils literal"><span class="pre">bjam</span></tt> as follows:</p>
|
||||
<pre class="literal-block">
|
||||
@ -491,11 +491,13 @@ bjam <strong>--build-dir=</strong><a class="reference internal" href="#id12"><em
|
||||
</pre>
|
||||
<p>For example, your session might look like this:<a class="footnote-reference" href="#continuation" id="id13"><sup>4</sup></a></p>
|
||||
<pre class="literal-block">
|
||||
C:\WINDOWS> cd <tt class="docutils literal"><span class="pre">C:\Program</span> <span class="pre">Files\boost\</span></tt><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt>
|
||||
<tt class="docutils literal"><span class="pre">C:\Program</span> <span class="pre">Files\boost\</span></tt><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt>> bjam <strong>^</strong>
|
||||
More? <strong>--build-dir=</strong>C:\temp\build-boost <strong>^</strong>
|
||||
C:\WINDOWS> cd <tt class="docutils literal"><span class="pre">C:\Program</span> <span class="pre">Files\boost\</span></tt><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt>
|
||||
<tt class="docutils literal"><span class="pre">C:\Program</span> <span class="pre">Files\boost\</span></tt><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt>> bjam <strong>^</strong>
|
||||
More? <strong>--build-dir=</strong>"C:\Documents and Settings\dave\build-boost" <strong>^</strong>
|
||||
More? <strong>--toolset=</strong>msvc stage
|
||||
</pre>
|
||||
<p>Be sure to read <a class="reference internal" href="#continuation">this note</a> about the appearance of <tt class="docutils literal"><span class="pre">^</span></tt>,
|
||||
<tt class="docutils literal"><span class="pre">More?</span></tt> and quotation marks (<tt class="docutils literal"><span class="pre">"</span></tt>) in that line.</p>
|
||||
<!-- Copyright David Abrahams 2006. Distributed under the Boost -->
|
||||
<!-- Software License, Version 1.0. (See accompanying -->
|
||||
<!-- file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) -->
|
||||
@ -523,7 +525,7 @@ be interested in:</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="expected-build-output">
|
||||
<h2><a class="toc-backref" href="#id37">5.3 Expected Build Output</a></h2>
|
||||
<h2><a class="toc-backref" href="#id38">5.3 Expected Build Output</a></h2>
|
||||
<p>During the process of building Boost libraries, you can expect to
|
||||
see some messages printed on the console. These may include</p>
|
||||
<ul>
|
||||
@ -547,7 +549,7 @@ look something like:</p>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="in-case-of-build-errors">
|
||||
<h2><a class="toc-backref" href="#id38">5.4 In Case of Build Errors</a></h2>
|
||||
<h2><a class="toc-backref" href="#id39">5.4 In Case of Build Errors</a></h2>
|
||||
<p>The only error messages you see when building Boost—if any—should
|
||||
be related to the IOStreams library's support of zip and bzip2
|
||||
formats as described <a class="reference external" href="../../libs/iostreams/doc/installation.html">here</a>. Install the relevant development
|
||||
@ -565,7 +567,7 @@ questions about configuring Boost for your compiler to the
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="link-your-program-to-a-boost-library">
|
||||
<h1><a class="toc-backref" href="#id39">6 Link Your Program to a Boost Library</a></h1>
|
||||
<h1><a class="toc-backref" href="#id40">6 Link Your Program to a Boost Library</a></h1>
|
||||
<p>To demonstrate linking with a Boost binary library, we'll use the
|
||||
following simple program that extracts the subject lines from
|
||||
emails. It uses the <a class="reference external" href="../../libs/regex/index.html">Boost.Regex</a> library, which has a
|
||||
@ -610,7 +612,7 @@ GCC users should refer to the <a class="reference external" href="unix-variants.
|
||||
variant OSes</a> for the appropriate command-line options to use.</p>
|
||||
</div>
|
||||
<div class="section" id="link-from-within-the-visual-studio-ide">
|
||||
<h2><a class="toc-backref" href="#id40">6.1 Link From Within the Visual Studio IDE</a></h2>
|
||||
<h2><a class="toc-backref" href="#id41">6.1 Link From Within the Visual Studio IDE</a></h2>
|
||||
<p>Starting with the <a class="reference internal" href="#vs-header-only">header-only example project</a> we created
|
||||
earlier:</p>
|
||||
<ol class="arabic simple">
|
||||
@ -618,24 +620,24 @@ earlier:</p>
|
||||
select <em>Properties</em> from the resulting pop-up menu</li>
|
||||
<li>In <em>Configuration Properties</em> > <em>Linker</em> > <em>Additional Library
|
||||
Directories</em>, enter the path to the Boost binaries,
|
||||
e.g. <tt class="docutils literal"><span class="pre">C:\Program</span> <span class="pre">Files\boost\</span></tt><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt><tt class="docutils literal"><span class="pre">\lib\</span></tt>.</li>
|
||||
e.g. <tt class="docutils literal"><span class="pre">C:\Program</span> <span class="pre">Files\boost\</span></tt><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt><tt class="docutils literal"><span class="pre">\lib\</span></tt>.</li>
|
||||
<li>From the <em>Build</em> menu, select <em>Build Solution</em>.</li>
|
||||
</ol>
|
||||
<p><a class="reference internal" href="#test-your-program"><em>skip to the next step</em></a></p>
|
||||
</div>
|
||||
<div class="section" id="or-link-from-the-command-prompt">
|
||||
<h2><a class="toc-backref" href="#id41">6.2 Or, Link From the Command Prompt</a></h2>
|
||||
<h2><a class="toc-backref" href="#id42">6.2 Or, Link From the Command Prompt</a></h2>
|
||||
<p>For example, we can compile and link the above program from the
|
||||
Visual C++ command-line by simply adding the <strong>bold</strong> text below to
|
||||
the command line we used earlier, assuming your Boost binaries are
|
||||
in <tt class="docutils literal"><span class="pre">C:\Program</span> <span class="pre">Files\boost\</span></tt><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt><tt class="docutils literal"><span class="pre">\lib</span></tt>:</p>
|
||||
in <tt class="docutils literal"><span class="pre">C:\Program</span> <span class="pre">Files\boost\</span></tt><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt><tt class="docutils literal"><span class="pre">\lib</span></tt>:</p>
|
||||
<pre class="literal-block">
|
||||
cl /EHsc /I <em>path\to\</em><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt> example.cpp <strong>^</strong>
|
||||
<strong>/link /LIBPATH:</strong> <strong>C:\Program Files\boost\</strong><strong>boost_1_34_1</strong><strong>\lib</strong>
|
||||
cl /EHsc /I <em>path\to\</em><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt> example.cpp <strong>^</strong>
|
||||
<strong>/link /LIBPATH:</strong> <strong>C:\Program Files\boost\</strong><strong>boost_1_35_0</strong><strong>\lib</strong>
|
||||
</pre>
|
||||
</div>
|
||||
<div class="section" id="library-naming">
|
||||
<h2><a class="toc-backref" href="#id42">6.3 Library Naming</a></h2>
|
||||
<h2><a class="toc-backref" href="#id43">6.3 Library Naming</a></h2>
|
||||
<div class="note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p>If, like Visual C++, your compiler supports auto-linking,
|
||||
@ -657,7 +659,7 @@ following elements:</p>
|
||||
<dd><em>Prefix</em>: except on Microsoft Windows, every Boost library
|
||||
name begins with this string. On Windows, only ordinary static
|
||||
libraries use the <tt class="docutils literal"><span class="pre">lib</span></tt> prefix; import libraries and DLLs do
|
||||
not.<a class="footnote-reference" href="#distinct" id="id19"><sup>6</sup></a></dd>
|
||||
not.<a class="footnote-reference" href="#distinct" id="id20"><sup>6</sup></a></dd>
|
||||
<dt><tt class="docutils literal"><span class="pre">boost_regex</span></tt></dt>
|
||||
<dd><em>Library name</em>: all boost library filenames begin with <tt class="docutils literal"><span class="pre">boost_</span></tt>.</dd>
|
||||
<dt><tt class="docutils literal"><span class="pre">-vc71</span></tt></dt>
|
||||
@ -695,14 +697,14 @@ libraries.</td>
|
||||
<td>using a special <a class="reference external" href="../../libs/python/doc/building.html#variants">debug build of Python</a>.</td>
|
||||
</tr>
|
||||
<tr><td><tt class="docutils literal"><span class="pre">d</span></tt></td>
|
||||
<td>building a debug version of your code.<a class="footnote-reference" href="#debug-abi" id="id20"><sup>7</sup></a></td>
|
||||
<td>building a debug version of your code.<a class="footnote-reference" href="#debug-abi" id="id21"><sup>7</sup></a></td>
|
||||
</tr>
|
||||
<tr><td><tt class="docutils literal"><span class="pre">p</span></tt></td>
|
||||
<td>using the STLPort standard library rather than the default one supplied with
|
||||
your compiler.</td>
|
||||
</tr>
|
||||
<tr><td><tt class="docutils literal"><span class="pre">n</span></tt></td>
|
||||
<td>using STLPort's deprecated “native iostreams” feature.<a class="footnote-reference" href="#native" id="id21"><sup>8</sup></a></td>
|
||||
<td>using STLPort's deprecated “native iostreams” feature.<a class="footnote-reference" href="#native" id="id22"><sup>8</sup></a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@ -735,7 +737,7 @@ version number, will also be created.</dd>
|
||||
<!-- file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) -->
|
||||
</div>
|
||||
<div class="section" id="test-your-program">
|
||||
<h2><a class="toc-backref" href="#id43">6.4 Test Your Program</a></h2>
|
||||
<h2><a class="toc-backref" href="#id44">6.4 Test Your Program</a></h2>
|
||||
<p>To test our subject extraction, we'll filter the following text
|
||||
file. Copy it out of your browser and save it as <tt class="docutils literal"><span class="pre">jayne.txt</span></tt>:</p>
|
||||
<pre class="literal-block">
|
||||
@ -757,7 +759,7 @@ Spoil Rock Hunter?”</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="conclusion-and-further-resources">
|
||||
<h1><a class="toc-backref" href="#id44">7 Conclusion and Further Resources</a></h1>
|
||||
<h1><a class="toc-backref" href="#id45">7 Conclusion and Further Resources</a></h1>
|
||||
<p>This concludes your introduction to Boost and to integrating it
|
||||
with your programs. As you start using Boost in earnest, there are
|
||||
surely a few additional points you'll wish we had covered. One day
|
||||
@ -786,7 +788,7 @@ mailing list</a>.</p>
|
||||
<colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id2">[1]</a></td><td>If you prefer not to download executable programs,
|
||||
download <a class="reference external" href="http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041"><tt class="docutils literal"><span class="pre">boost_1_34_1</span></tt><tt class="docutils literal"><span class="pre">.zip</span></tt></a> and use an external tool to decompress
|
||||
download <a class="reference external" href="http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041"><tt class="docutils literal"><span class="pre">boost_1_35_0</span></tt><tt class="docutils literal"><span class="pre">.zip</span></tt></a> and use an external tool to decompress
|
||||
it. We don't recommend using Windows' built-in decompression as
|
||||
it can be painfully slow for large archives.</td></tr>
|
||||
</tbody>
|
||||
@ -813,11 +815,25 @@ used in the examples.</td></tr>
|
||||
<table class="docutils footnote" frame="void" id="continuation" rules="none">
|
||||
<colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id13">[4]</a></td><td>In this example, the caret character <tt class="docutils literal"><span class="pre">^</span></tt> is a
|
||||
way of continuing the command on multiple lines. The command
|
||||
prompt responds with <tt class="docutils literal"><span class="pre">More?</span></tt> to prompt for more input. Feel
|
||||
free to omit the carets and subsequent newlines; we used them so
|
||||
the example would fit on a page of reasonable width.</td></tr>
|
||||
<tr><td class="label"><a class="fn-backref" href="#id13">[4]</a></td><td><p class="first">In this example, the caret character <tt class="docutils literal"><span class="pre">^</span></tt> is a
|
||||
way of continuing the command on multiple lines, and must be the
|
||||
<strong>final character</strong> used on the line to be continued (i.e. do
|
||||
not follow it with spaces). The command prompt responds with
|
||||
<tt class="docutils literal"><span class="pre">More?</span></tt> to prompt for more input. Feel free to omit the
|
||||
carets and subsequent newlines; we used them so the example
|
||||
would fit on a page of reasonable width.</p>
|
||||
<p>The command prompt treats each bit of whitespace in the command
|
||||
as an argument separator. That means quotation marks (<tt class="docutils literal"><span class="pre">"</span></tt>)
|
||||
are required to keep text together whenever a single
|
||||
command-line argument contains spaces, as in</p>
|
||||
<pre class="literal-block">
|
||||
--build-dir=<span class="raw-html"><strong style="background-color:#B4FFB4">"</strong></span>C:\Documents<span class="raw-html"><strong style="color:#B4B4B4; background-color:#B4FFB4">_</strong></span>and<span class="raw-html"><strong style="color:#B4B4B4; background-color:#B4FFB4">_</strong></span>Settings\dave\build-boost<span class="raw-html"><strong style="background-color:#B4FFB4">"</strong></span>
|
||||
</pre>
|
||||
<p>Also, for example, you can't add spaces around the <tt class="docutils literal"><span class="pre">=</span></tt> sign as in</p>
|
||||
<pre class="last literal-block">
|
||||
--build-dir<span class="raw-html"><strong style="color:#B4B4B4; background-color:#FFB4B4">_</strong></span>=<span class="raw-html"><strong style="color:#B4B4B4; background-color:#FFB4B4">_</strong></span>"C:\Documents and Settings\dave\build-boost"
|
||||
</pre>
|
||||
</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<!-- Copyright David Abrahams 2006. Distributed under the Boost -->
|
||||
@ -837,7 +853,7 @@ have any source code mechanism for suppressing warnings.</td></tr>
|
||||
<table class="docutils footnote" frame="void" id="distinct" rules="none">
|
||||
<colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id19">[6]</a></td><td>This convention distinguishes the static version of
|
||||
<tr><td class="label"><a class="fn-backref" href="#id20">[6]</a></td><td>This convention distinguishes the static version of
|
||||
a Boost library from the import library for an
|
||||
identically-configured Boost DLL, which would otherwise have the
|
||||
same name.</td></tr>
|
||||
@ -846,7 +862,7 @@ same name.</td></tr>
|
||||
<table class="docutils footnote" frame="void" id="debug-abi" rules="none">
|
||||
<colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id20">[7]</a></td><td>These libraries were compiled without optimization
|
||||
<tr><td class="label"><a class="fn-backref" href="#id21">[7]</a></td><td>These libraries were compiled without optimization
|
||||
or inlining, with full debug symbols enabled, and without
|
||||
<tt class="docutils literal"><span class="pre">NDEBUG</span></tt> <tt class="docutils literal"><span class="pre">#define</span></tt>d. Although it's true that sometimes
|
||||
these choices don't affect binary compatibility with other
|
||||
@ -856,7 +872,7 @@ compiled code, you can't count on that with Boost libraries.</td></tr>
|
||||
<table class="docutils footnote" frame="void" id="native" rules="none">
|
||||
<colgroup><col class="label" /><col /></colgroup>
|
||||
<tbody valign="top">
|
||||
<tr><td class="label"><a class="fn-backref" href="#id21">[8]</a></td><td>This feature of STLPort is deprecated because it's
|
||||
<tr><td class="label"><a class="fn-backref" href="#id22">[8]</a></td><td>This feature of STLPort is deprecated because it's
|
||||
impossible to make it work transparently to the user; we don't
|
||||
recommend it.</td></tr>
|
||||
</tbody>
|
||||
|
@ -10,6 +10,9 @@
|
||||
:alt: Boost
|
||||
:class: boost-logo
|
||||
|
||||
.. role:: raw-html(raw)
|
||||
:format: html
|
||||
|
||||
__ ../../index.htm
|
||||
|
||||
.. section-numbering::
|
||||
@ -201,9 +204,14 @@ For example, your session might look like this: [#continuation]_
|
||||
|
||||
C:\\WINDOWS> cd |default-root|
|
||||
|default-root|> bjam **^**
|
||||
More? **--build-dir=**\ C:\\temp\\build-boost **^**
|
||||
More? **--build-dir=**\ "C:\\Documents and Settings\\dave\\build-boost" **^**
|
||||
More? **--toolset=**\ msvc stage
|
||||
|
||||
Be sure to read `this note`__ about the appearance of ``^``,
|
||||
``More?`` and quotation marks (``"``) in that line.
|
||||
|
||||
__ continuation_
|
||||
|
||||
.. include:: detail/build-from-source-tail.rst
|
||||
|
||||
.. _auto-linking:
|
||||
@ -300,10 +308,27 @@ Spoil Rock Hunter?”
|
||||
used in the examples.
|
||||
|
||||
.. [#continuation] In this example, the caret character ``^`` is a
|
||||
way of continuing the command on multiple lines. The command
|
||||
prompt responds with ``More?`` to prompt for more input. Feel
|
||||
free to omit the carets and subsequent newlines; we used them so
|
||||
the example would fit on a page of reasonable width.
|
||||
way of continuing the command on multiple lines, and must be the
|
||||
**final character** used on the line to be continued (i.e. do
|
||||
not follow it with spaces). The command prompt responds with
|
||||
``More?`` to prompt for more input. Feel free to omit the
|
||||
carets and subsequent newlines; we used them so the example
|
||||
would fit on a page of reasonable width.
|
||||
|
||||
The command prompt treats each bit of whitespace in the command
|
||||
as an argument separator. That means quotation marks (``"``)
|
||||
are required to keep text together whenever a single
|
||||
command-line argument contains spaces, as in
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
--build-dir=\ :raw-html:`<strong style="background-color:#B4FFB4">"</strong>`\ C:\\Documents\ :raw-html:`<strong style="color:#B4B4B4; background-color:#B4FFB4">_</strong>`\ and\ :raw-html:`<strong style="color:#B4B4B4; background-color:#B4FFB4">_</strong>`\ Settings\\dave\\build-boost\ \ :raw-html:`<strong style="background-color:#B4FFB4">"</strong>`
|
||||
|
||||
Also, for example, you can't add spaces around the ``=`` sign as in
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
--build-dir\ :raw-html:`<strong style="color:#B4B4B4; background-color:#FFB4B4">_</strong>`\ =\ :raw-html:`<strong style="color:#B4B4B4; background-color:#FFB4B4">_</strong>`\ "C:\\Documents and Settings\\dave\\build-boost"
|
||||
|
||||
.. |boost.zip| replace:: |boost_ver|\ ``.zip``
|
||||
|
||||
|
103
header.htm
103
header.htm
@ -1,103 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
||||
<title>Boost Header policy</title>
|
||||
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
||||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||||
<meta name="Microsoft Border" content="none, default">
|
||||
</head>
|
||||
|
||||
<body bgcolor="#FFFFFF" text="#000000">
|
||||
|
||||
<table summary="Navigational header"
|
||||
border="1" bgcolor="#007F7F" cellpadding="2">
|
||||
<tr>
|
||||
<td bgcolor="#FFFFFF"><img src="../boost.png" alt="boost.png (6897 bytes)" width="277" height="86"></td>
|
||||
<td><a href="../index.htm"><font face="Arial" color="#FFFFFF"><big>Home</big></font></a></td>
|
||||
<td><a href="../libs/libraries.htm"><font face="Arial" color="#FFFFFF"><big>Libraries</big></font></a></td>
|
||||
<td><a href="../people/people.htm"><font face="Arial" color="#FFFFFF"><big>People</big></font></a></td>
|
||||
<td><a href="faq.htm"><font face="Arial" color="#FFFFFF"><big>FAQ</big></font></a></td>
|
||||
<td><a href="index.htm"><font face="Arial" color="#FFFFFF"><big>More</big></font></a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<h1>Boost Header Policy</h1>
|
||||
<p>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".</p>
|
||||
<p>Here are the standards for boost headers. Many of
|
||||
these are also reasonable guidelines for general use.
|
||||
<ul>
|
||||
<li>Header filenames should have a .hpp (lowercase) extension. </li>
|
||||
<li>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 <a href="#SampleHeader">sample
|
||||
header</a> uses the Boost convention of all uppercase letters, with the
|
||||
header name prefixed by the namespace name, and suffixed with HPP, separated
|
||||
by underscores.</li>
|
||||
<li>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 <tt>boost</tt>.</li>
|
||||
|
||||
<li>Make sure that a translation unit consisting of just the
|
||||
contents of the header file will compile successfully.</li>
|
||||
|
||||
<li>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 <tt>#include</tt>
|
||||
directives. Thus the header <a href="#SampleHeader">sample header</a>
|
||||
would be included by <tt>#include <boost/furball.hpp></tt></li>
|
||||
<li>The preferred ordering for class definitions is public members, protected
|
||||
members, and finally private members.</li>
|
||||
<li>Include the boost/config.hpp <a href="../libs/config/config.htm">configuration
|
||||
header</a> if there is a need to deal with compiler or platform
|
||||
configuration issues.</li>
|
||||
</ul>
|
||||
<h2><a name="SampleHeader"></a>Sample Header</h2>
|
||||
<pre><tt>// Boost general library furball.hpp header file ---------------------------//
|
||||
|
||||
<<i> Copyright and license notice</i>, as indicated in the <a href="license_info.html">license page</a> >
|
||||
|
||||
// See http://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</tt></pre>
|
||||
<h2>Coding Style</h2>
|
||||
<p>The alert reader will have noticed that the <a href="#SampleHeader">sample
|
||||
header</a> 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.</p>
|
||||
<hr>
|
||||
<p>Revised <!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan -->02 October, 2003<!--webbot bot="Timestamp" endspan i-checksum="38549" --></p>
|
||||
|
||||
<p>© Copyright Beman Dawes 1998</p>
|
||||
<p>
|
||||
Distributed under the Boost Software License, Version 1.0. (See
|
||||
accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy
|
||||
at <a href="http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>)
|
||||
</p>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
211
imp_vars.htm
211
imp_vars.htm
@ -1,211 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
||||
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
||||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||||
<title>Boost Implementation Variations</title>
|
||||
</head>
|
||||
|
||||
<body link="#0000ff" vlink="#800080" bgcolor="#FFFFFF" text="#000000">
|
||||
|
||||
<table summary="Navigational header"
|
||||
border="1" bgcolor="#007F7F" cellpadding="2">
|
||||
<tr>
|
||||
<td bgcolor="#FFFFFF"><img src="../boost.png" alt="boost.png (6897 bytes)" width="277" height="86"></td>
|
||||
<td><a href="../index.htm"><font face="Arial" color="#FFFFFF"><big>Home</big></font></a></td>
|
||||
<td><a href="../libs/libraries.htm"><font face="Arial" color="#FFFFFF"><big>Libraries</big></font></a></td>
|
||||
<td><a href="../people/people.htm"><font face="Arial" color="#FFFFFF"><big>People</big></font></a></td>
|
||||
<td><a href="faq.htm"><font face="Arial" color="#FFFFFF"><big>FAQ</big></font></a></td>
|
||||
<td><a href="index.htm"><font face="Arial" color="#FFFFFF"><big>More</big></font></a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<h1>Boost Implementation Variations</h1>
|
||||
<h2>Separation of interface and implementation</h2>
|
||||
<p>The interface specifications for boost.org library components (as well as for
|
||||
quality software in general) are conceptually separate from implementations of
|
||||
those interfaces. This may not be obvious, particularly when a component is
|
||||
implemented entirely within a header, but this separation of interface and
|
||||
implementation is always assumed. From the perspective of those concerned with
|
||||
software design, portability, and standardization, the interface is what is
|
||||
important, while the implementation is just a detail.</p>
|
||||
<p>Dietmar Kühl, one of the original boost.org contributors, comments "The
|
||||
main contribution is the interface, which is augmented with an implementation,
|
||||
proving that it is possible to implement the corresponding class and providing a
|
||||
free implementation."</p>
|
||||
|
||||
<h2>Implementation variations</h2>
|
||||
|
||||
<p>There may be a need for multiple implementations of an interface, to
|
||||
accommodate either platform dependencies or performance tradeoffs. Examples of
|
||||
platform dependencies include compiler shortcomings, file systems, thread
|
||||
mechanisms, and graphical user interfaces. The classic example of a performance
|
||||
tradeoff is a fast implementation which uses a lot of memory versus a slower
|
||||
implementation which uses less memory.</p>
|
||||
<p>Boost libraries generally use a <a href="../libs/config/config.htm">configuration
|
||||
header</a>, boost/config.hpp, to capture compiler and platform
|
||||
dependencies. Although the use of boost/config.hpp is not required, it is
|
||||
the preferred approach for simple configuration problems. </p>
|
||||
<h2>Boost policy</h2>
|
||||
<p>The Boost policy is to avoid platform dependent variations in interface
|
||||
specifications, but supply implementations which are usable over a wide range of
|
||||
platforms and applications. That means boost libraries will use the
|
||||
techniques below described as appropriate for dealing with platform
|
||||
dependencies.</p>
|
||||
<p>The Boost policy toward implementation variations designed to enhance
|
||||
performance is to avoid them unless the benefits greatly exceed the full
|
||||
costs. The term "full costs" is intended to include both
|
||||
tangible costs like extra maintenance, and intangible cost like increased
|
||||
difficulty in user understanding.</p>
|
||||
|
||||
<h2>Techniques for providing implementation variations</h2>
|
||||
|
||||
<p>Several techniques may be used to provide implementation variations. Each is
|
||||
appropriate in some situations, and not appropriate in other situations.</p>
|
||||
<h3>Single general purpose implementation</h3>
|
||||
<p>The first technique is to simply not provide implementation variation at
|
||||
all. Instead, provide a single general purpose implementation, and forgo
|
||||
the increased complexity implied by all other techniques.</p>
|
||||
<p><b>Appropriate:</b> When it is possible to write a single portable
|
||||
implementation which has reasonable performance across a wide range of
|
||||
platforms. Particularly appropriate when alternative implementations differ only
|
||||
in esoteric ways.</p>
|
||||
<p><b>Not appropriate:</b> When implementation requires platform specific
|
||||
features, or when there are multiple implementation possible with widely
|
||||
differing performance characteristics.</p>
|
||||
<p>Beman Dawes comments "In design discussions some implementation is often
|
||||
alleged to be much faster than another, yet a timing test discovers no
|
||||
significant difference. The lesson is that while algorithmic differences may
|
||||
affect speed dramatically, coding differences such as changing a class from
|
||||
virtual to non-virtual members or removing a level of indirection are unlikely
|
||||
to make any measurable difference unless deep in an inner loop. And even in an
|
||||
inner loop, modern CPUs often execute such competing code sequences in the
|
||||
same number of clock cycles! A single general purpose implementation is
|
||||
often just fine."</p>
|
||||
<p>Or as Donald Knuth said, "Premature optimization is the root of all
|
||||
evil." (Computing Surveys, vol 6, #4, p 268).</p>
|
||||
<h3>Macros</h3>
|
||||
<p>While the evils of macros are well known, there remain a few cases where
|
||||
macros are the preferred solution:</p>
|
||||
<blockquote>
|
||||
<ul>
|
||||
<li> Preventing multiple inclusion of headers via #include guards.</li>
|
||||
<li> Passing minor configuration information from a configuration
|
||||
header to other files.</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
<p><b>Appropriate:</b> For small compile-time variations which would
|
||||
otherwise be costly or confusing to install, use, or maintain. More appropriate
|
||||
to communicate within and between library components than to communicate with
|
||||
library users.</p>
|
||||
<p><b>Not appropriate: </b> If other techniques will do.</p>
|
||||
<p>To minimize the negative aspects of macros:</p>
|
||||
<blockquote>
|
||||
<ul>
|
||||
<li>Only use macros when they are clearly superior to other
|
||||
techniques. They should be viewed as a last resort.</li>
|
||||
<li>Names should be all uppercase, and begin with the namespace name. This
|
||||
will minimize the chance of name collisions. For example, the #include
|
||||
guard for a boost header called foobar.h might be named BOOST_FOOBAR_H.</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
<h3>Separate files</h3>
|
||||
<p>A library component can have multiple variations, each contained in its own
|
||||
separate file or files. The files for the most appropriate variation are
|
||||
copied to the appropriate include or implementation directories at installation
|
||||
time.</p>
|
||||
<p>The way to provide this approach in boost libraries is to include specialized
|
||||
implementations as separate files in separate sub-directories in the .ZIP
|
||||
distribution file. For example, the structure within the .ZIP distribution file
|
||||
for a library named foobar which has both default and specialized variations
|
||||
might look something like:</p>
|
||||
<blockquote>
|
||||
<pre>foobar.h // The default header file
|
||||
foobar.cpp // The default implementation file
|
||||
readme.txt // Readme explains when to use which files
|
||||
self_contained/foobar.h // A variation with everything in the header
|
||||
linux/foobar.cpp // Implementation file to replace the default
|
||||
win32/foobar.h // Header file to replace the default
|
||||
win32/foobar.cpp // Implementation file to replace the default</pre>
|
||||
</blockquote>
|
||||
<p><b>Appropriate:</b> When different platforms require different
|
||||
implementations, or when there are major performance differences between
|
||||
possible implementations. </p>
|
||||
<p><b>Not appropriate:</b> When it makes sense to use more that one of the
|
||||
variations in the same installation.</p>
|
||||
<h3>Separate components</h3>
|
||||
<p>Rather than have several implementation variations of a single component,
|
||||
supply several separate components. For example, the Boost library currently
|
||||
supplies <code>scoped_ptr</code> and <code>shared_ptr</code> classes rather than
|
||||
a single <code>smart_ptr</code> class parameterized to distinguish between the
|
||||
two cases. There are several ways to make the component choice:</p>
|
||||
<blockquote>
|
||||
<ul>
|
||||
<li>Hardwired by the programmer during coding.</li>
|
||||
<li>Chosen by programmer written runtime logic (trading off some extra
|
||||
space, time, and program complexity for the ability to select the
|
||||
implementation at run-time.)</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
<p><b>Appropriate: </b>When the interfaces for the variations diverge, and when
|
||||
it is reasonably to use more than one of the variations. When run-time selection
|
||||
of implementation is called for.</p>
|
||||
<p><b>Not appropriate:</b> When the variations are data type, traits, or
|
||||
specialization variations which can be better handled by making the component a
|
||||
template. Also not appropriate when choice of variation is best done by some
|
||||
setup or installation mechanism outside of the program itself. Thus
|
||||
usually not appropriate to cope with platform differences.</p>
|
||||
<p><b>Note:</b> There is a related technique where the interface is specified as
|
||||
an abstract (pure virtual) base class (or an interface definition language), and
|
||||
the implementation choice is passed off to some third-party, such as a
|
||||
dynamic-link library or object-request broker. While that is a powerful
|
||||
technique, it is way beyond the scope of this discussion.</p>
|
||||
<h3>Template-based approaches</h3>
|
||||
<p>Turning a class or function into a template is often an elegant way to cope
|
||||
with variations. Template-based approaches provide optimal space and time
|
||||
efficiency in return for constraining the implementation selection to compile
|
||||
time. </p>
|
||||
<p>Important template techniques include:</p>
|
||||
<blockquote>
|
||||
<ul>
|
||||
<li>Data type parameterization. This allows a single component to
|
||||
operate on a variety of data types, and is why templates were originally
|
||||
invented.</li>
|
||||
<li>Traits parameterization. If parameterization is complex, bundling
|
||||
up aspects into a single traits helper class can allow great variation
|
||||
while hiding messy details. The C++ Standard Library provides
|
||||
several examples of this idiom, such as <code>iterator_traits<></code>
|
||||
(24.3.1 lib.iterator.traits) and <tt>char_traits<></tt> (21.2
|
||||
lib.char.traits).</li>
|
||||
<li>Specialization. A template parameter can be used purely for the
|
||||
purpose of selecting a specialization. For example:</li>
|
||||
</ul>
|
||||
<blockquote>
|
||||
<blockquote>
|
||||
<pre>SomeClass<fast> my_fast_object; // fast and small are empty classes
|
||||
SomeClass<small> my_small_object; // used just to select specialization</pre>
|
||||
</blockquote>
|
||||
</blockquote>
|
||||
</blockquote>
|
||||
<p><b>Appropriate: </b>When the need for variation is due to data type or
|
||||
traits, or is performance related like selecting among several algorithms, and
|
||||
when a program might reasonably use more than one of the variations.</p>
|
||||
<p><b>Not appropriate:</b> When the interfaces for variations are
|
||||
different, or when choice of variation is best done by some mechanism outside of
|
||||
the program itself. Thus usually not appropriate to cope with platform
|
||||
differences.</p>
|
||||
<hr>
|
||||
<p>Revised <!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan -->02 October, 2003<!--webbot bot="Timestamp" endspan i-checksum="38549" --></p>
|
||||
|
||||
<p>© Copyright Beman Dawes 2001</p>
|
||||
|
||||
<p>Distributed under the Boost Software License, Version 1.0. (See
|
||||
accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy
|
||||
at <a href=
|
||||
"http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>)
|
||||
</p>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
@ -79,6 +79,9 @@
|
||||
to request new library features.</p>
|
||||
<p><b><a href="cpp_committee_meetings.html">C++ Committee Meetings</a></b> FAQ for
|
||||
Boost Members wishing to attend a standards committee meeting.</p>
|
||||
<p><b><a href="boost_soc_06_overview.html">An overview of Boost participation in
|
||||
Google Summer of Code™ 2006</a></b> A report of our first experience
|
||||
in this open source initiative.</p>
|
||||
<p><b><a href="version_history.html">Version History</a></b> Changes
|
||||
and additions in past Boost releases.</p>
|
||||
</blockquote>
|
||||
|
@ -1,328 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<meta http-equiv="Content-Type"
|
||||
content="text/html; charset=iso-8859-1">
|
||||
<meta name="Template"
|
||||
content="C:\PROGRAM FILES\MICROSOFT OFFICE\OFFICE\html.dot">
|
||||
<meta name="GENERATOR" content="Microsoft FrontPage Express 2.0">
|
||||
<title></title>
|
||||
</head>
|
||||
|
||||
<body bgcolor="#FFFFFF" link="#0000FF" vlink="#800080">
|
||||
|
||||
<h2 align="center">Coding Guidelines for Integral Constant
|
||||
Expressions</h2>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<h3>What is an Integral Constant Expression?</h3>
|
||||
|
||||
<p>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:</p>
|
||||
|
||||
<ol>
|
||||
<li>A literal integral value, for example 0u or 3L.</li>
|
||||
<li>An enumerator value.</li>
|
||||
<li>Global integral constants, for example: <font
|
||||
face="Courier New"><code><br>
|
||||
</code></font><code>const int my_INTEGRAL_CONSTANT = 3;</code></li>
|
||||
<li>Static member constants, for example: <br>
|
||||
<code>struct myclass<br>
|
||||
{ static const int value = 0; };</code></li>
|
||||
<li>Member enumerator values, for example:<br>
|
||||
<code>struct myclass<br>
|
||||
{ enum{ value = 0 }; };</code></li>
|
||||
<li>Non-type template parameters of integral or enumerator
|
||||
type.</li>
|
||||
<li>The result of a <code>sizeof</code> expression, for
|
||||
example:<br>
|
||||
<code>sizeof(foo(a, b, c))</code></li>
|
||||
<li>The result of a <code>static_cast</code>, where the
|
||||
target type is an integral or enumerator type, and the
|
||||
argument is either another integral constant expression,
|
||||
or a floating-point literal.</li>
|
||||
<li>The result of applying a binary operator to two integral
|
||||
constant expressions: <br>
|
||||
<code>INTEGRAL_CONSTANT1 op INTEGRAL_CONSTANT2 <br>
|
||||
p</code>rovided that the operator is not an assignment
|
||||
operator, or comma operator.</li>
|
||||
<li>The result of applying a unary operator to an integral
|
||||
constant expression: <br>
|
||||
<code>op INTEGRAL_CONSTANT1<br>
|
||||
</code>provided that the operator is not the increment or
|
||||
decrement operator.</li>
|
||||
</ol>
|
||||
|
||||
<p> </p>
|
||||
|
||||
<h3>Coding Guidelines</h3>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p><b><i>When declaring constants that are class members always
|
||||
use the macro BOOST_STATIC_CONSTANT.</i></b></p>
|
||||
|
||||
<pre>template <class T>
|
||||
struct myclass
|
||||
{
|
||||
BOOST_STATIC_CONSTANT(int, value = sizeof(T));
|
||||
};</pre>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p><b><i>Don't declare integral constant expressions whose type
|
||||
is wider than int.</i></b></p>
|
||||
|
||||
<p>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 <b>int</b>.</p>
|
||||
|
||||
<p><b><i>Don't use logical operators in integral constant
|
||||
expressions; use template meta-programming instead.</i></b></p>
|
||||
|
||||
<p>The header <boost/type_traits/ice.hpp> contains a number
|
||||
of workaround templates, that fulfil the role of logical
|
||||
operators, for example instead of:</p>
|
||||
|
||||
<p><code>INTEGRAL_CONSTANT1 || INTEGRAL_CONSTANT2</code></p>
|
||||
|
||||
<p>Use:</p>
|
||||
|
||||
<p><code>::boost::type_traits::ice_or<INTEGRAL_CONSTANT1,INTEGRAL_CONSTANT2>::value</code></p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p><b><i>Don't use any operators in an integral constant
|
||||
expression used as a non-type template parameter</i></b></p>
|
||||
|
||||
<p>Rather than:</p>
|
||||
|
||||
<p><code>typedef myclass<INTEGRAL_CONSTANT1 ==
|
||||
INTEGRAL_CONSTANT2> mytypedef;</code></p>
|
||||
|
||||
<p>Use:</p>
|
||||
|
||||
<p><code>typedef myclass< some_symbol> mytypedef;</code></p>
|
||||
|
||||
<p>Where <code>some_symbol</code> is the symbolic name of a an
|
||||
integral constant expression whose value is <code>(INTEGRAL_CONSTANT1
|
||||
== INTEGRAL_CONSTANT2).</code></p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p><b><i>Always use a fully qualified name to refer to an
|
||||
integral constant expression.</i></b></p>
|
||||
|
||||
<p>For example:</p>
|
||||
|
||||
<pre><code>typedef</code> myclass< ::boost::is_integral<some_type>::value> mytypedef;</pre>
|
||||
|
||||
<p>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 ::).</p>
|
||||
|
||||
<p><b><i>Always leave a space after a '<' and before '::'</i></b></p>
|
||||
|
||||
<p>For example:</p>
|
||||
|
||||
<pre><code>typedef</code> myclass< ::boost::is_integral<some_type>::value> mytypedef;
|
||||
^
|
||||
ensure there is space here!</pre>
|
||||
|
||||
<p>Rationale: <: is a legal digraph in it's own right, so <::
|
||||
is interpreted as the same as [:.</p>
|
||||
|
||||
<p><b><i>Don't use local names as integral constant expressions</i></b></p>
|
||||
|
||||
<p>Example:</p>
|
||||
|
||||
<pre>template <class T>
|
||||
struct foobar
|
||||
{
|
||||
BOOST_STATIC_CONSTANT(int, temp = computed_value);
|
||||
typedef myclass<temp> mytypedef; // error
|
||||
};</pre>
|
||||
|
||||
<p>Rationale: At least one compiler (Borland's) doesn't accept
|
||||
this.</p>
|
||||
|
||||
<p>Although it is possible to fix this by using:</p>
|
||||
|
||||
<pre>template <class T>
|
||||
struct foobar
|
||||
{
|
||||
BOOST_STATIC_CONSTANT(int, temp = computed_value);
|
||||
typedef foobar self_type;
|
||||
typedef myclass<(self_type::temp)> mytypedef; // OK
|
||||
};</pre>
|
||||
|
||||
<p>This breaks at least one other compiler (VC6), it is better to
|
||||
move the integral constant expression computation out into a
|
||||
separate traits class:</p>
|
||||
|
||||
<pre>template <class T>
|
||||
struct foobar_helper
|
||||
{
|
||||
BOOST_STATIC_CONSTANT(int, temp = computed_value);
|
||||
};
|
||||
|
||||
template <class T>
|
||||
struct foobar
|
||||
{
|
||||
typedef myclass< ::foobar_helper<T>::value> mytypedef; // OK
|
||||
};</pre>
|
||||
|
||||
<p><b><i>Don't use dependent default parameters for non-type
|
||||
template parameters.</i></b></p>
|
||||
|
||||
<p>For example:</p>
|
||||
|
||||
<pre>template <class T, int I = ::boost::is_integral<T>::value> // Error can't deduce value of I in some cases.
|
||||
struct foobar;</pre>
|
||||
|
||||
<p>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:</p>
|
||||
|
||||
<pre>template <class T, int I = 3> // OK, default value is not dependent
|
||||
struct foobar;</pre>
|
||||
|
||||
<p> </p>
|
||||
|
||||
<h3>Unresolved Issues</h3>
|
||||
|
||||
<p>The following issues are either unresolved or have fixes that
|
||||
are compiler specific, and/or break one or more of the coding
|
||||
guidelines.</p>
|
||||
|
||||
<p><b><i>Be careful of numeric_limits</i></b></p>
|
||||
|
||||
<p>There are three issues here:</p>
|
||||
|
||||
<ol>
|
||||
<li>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.</li>
|
||||
<li>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.</li>
|
||||
<li>There is a strange bug in VC6, where the members of std::numeric_limits
|
||||
can be "prematurely evaluated" in template
|
||||
code, for example:</li>
|
||||
</ol>
|
||||
|
||||
<pre>template <class T>
|
||||
struct limits_test
|
||||
{
|
||||
BOOST_STATIC_ASSERT(::std::numeric_limits<T>::is_specialized);
|
||||
};</pre>
|
||||
|
||||
<p>This code fails to compile with VC6 even though no instances
|
||||
of the template are ever created; for some bizarre reason <code>::std::numeric_limits<T>::is_specialized
|
||||
</code>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 <code>::std::numeric_limits<T>::is_specialized</code>
|
||||
with <code>::boost::is_arithmetic<T>::value</code>, then
|
||||
everything is fine. The following workaround also works but
|
||||
conflicts with the coding guidelines:</p>
|
||||
|
||||
<pre>template <class T>
|
||||
struct limits_test
|
||||
{
|
||||
BOOST_STATIC_CONSTANT(bool, check = ::std::numeric_limits<T>::is_specialized);
|
||||
BOOST_STATIC_ASSERT(check);
|
||||
};</pre>
|
||||
|
||||
<p>So it is probably best to resort to something like this:</p>
|
||||
|
||||
<pre>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
|
||||
};</pre>
|
||||
|
||||
<p><b><i>Be careful how you use the sizeof operator</i></b></p>
|
||||
|
||||
<p>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:</p>
|
||||
|
||||
<ol>
|
||||
<li>The argument is the name of a member-variable, or a local
|
||||
variable (code may not compile with VC6).</li>
|
||||
<li>The argument is an expression which involves the creation
|
||||
of a temporary (code will not compile with Borland C++).</li>
|
||||
<li>The argument is an expression involving an overloaded
|
||||
function call (code compiles but the result is a garbage
|
||||
value with Metroworks C++).</li>
|
||||
</ol>
|
||||
|
||||
<p><b><i>Don't use boost::is_convertible unless you have to</i></b></p>
|
||||
|
||||
<p>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).</p>
|
||||
|
||||
<hr>
|
||||
|
||||
<p><i>© Copyright Dr John Maddock 2001</i></p>
|
||||
<p><i>Distributed under the Boost Software License, Version 1.0. (See
|
||||
accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy
|
||||
at <a href=
|
||||
"http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>)</i></p>
|
||||
|
||||
<p> </p>
|
||||
|
||||
<p> </p>
|
||||
</body>
|
||||
</html>
|
931
lib_guide.htm
931
lib_guide.htm
@ -1,931 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<title>
|
||||
Boost Library Requirements and Guidelines
|
||||
</title>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
||||
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
||||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||||
<meta name="Microsoft Border" content="none, default">
|
||||
</head>
|
||||
|
||||
<body bgcolor="#FFFFFF" text="#000000">
|
||||
<table border="1" bgcolor="#007F7F" cellpadding="2">
|
||||
<tr>
|
||||
<td bgcolor="#FFFFFF">
|
||||
<img src="../boost.png" alt="boost.png (6897 bytes)" width="277"
|
||||
height="86">
|
||||
</td>
|
||||
<td>
|
||||
<a href="../index.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>Home</big></font></a>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
<a href="../libs/libraries.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>Libraries</big></font></a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="../people/people.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>People</big></font></a>
|
||||
</td>
|
||||
<td>
|
||||
|
||||
<a href="faq.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>FAQ</big></font></a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="index.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>More</big></font></a>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<h1 align="left">
|
||||
|
||||
Boost Library Requirements and Guidelines
|
||||
</h1>
|
||||
<p align="left">
|
||||
<a href="#Introduction">Introduction</a><br>
|
||||
<a href="#Requirements">Requirements</a><br>
|
||||
<a href="#License">License requirements</a><br>
|
||||
<a href="#Portability">Portability requirements</a><br>
|
||||
|
||||
<a href="#Ownership">Ownership</a><br>
|
||||
<a href="#Guidelines">Guidelines</a><br>
|
||||
<a href="#Design_and_Programming">Design and
|
||||
programming</a><br>
|
||||
<a href="#Directory_structure">Directory structure and
|
||||
filenames</a><br>
|
||||
<a href="#Naming_consistency">Naming
|
||||
consistency</a><br>
|
||||
|
||||
<a href="#Documentation">Documentation</a><br>
|
||||
<a href="#Rationale">Rationale</a><br>
|
||||
<a href=
|
||||
"#Exception-specification">Exception-specification rationale</a><br>
|
||||
<a href="#Naming">Naming conventions rationale</a><br>
|
||||
<a href="#code_fonts">Source code fonts
|
||||
rationale</a><br>
|
||||
|
||||
<a href="#Tabs">Tabs rationale</a><br>
|
||||
<a href="#JavaScript">ECMAScript/JavaScript
|
||||
rationale</a><br>
|
||||
<a href="#Rationale_rationale">Rationale
|
||||
rationale</a><br>
|
||||
<a href="#Acknowledgements">Acknowledgements
|
||||
rationale</a>
|
||||
</p>
|
||||
|
||||
<h2 align="left">
|
||||
<a name="Introduction" id="Introduction">Introduction</a>
|
||||
</h2>
|
||||
<p align="left">
|
||||
This page describes requirements and guidelines for the content of a
|
||||
library submitted to Boost.
|
||||
</p>
|
||||
<p align="left">
|
||||
See the <a href="submission_process.htm">Boost Library Submission
|
||||
Process</a> page for a description of the process involved.
|
||||
</p>
|
||||
|
||||
<h2 align="left">
|
||||
<a name="Requirements" id="Requirements">Requirements</a>
|
||||
</h2>
|
||||
<p>
|
||||
To avoid the frustration and wasted time of a proposed library being
|
||||
rejected, it must meets these requirements:
|
||||
</p>
|
||||
<ul>
|
||||
<li>The license must meet the <a href="#License">license requirements</a>
|
||||
|
||||
below. Restricted licenses like the GPL and LGPL are not acceptable.
|
||||
</li>
|
||||
<li>The copyright <a href="#Ownership">ownership</a> must be clear.
|
||||
</li>
|
||||
<li>The library must be generally useful and not restricted to a narrow
|
||||
problem domain.
|
||||
</li>
|
||||
<li>The library must meet the <a href="#Portability">portability
|
||||
requirements</a> below.
|
||||
|
||||
</li>
|
||||
<li>The library must come reasonably close to meeting the <a href=
|
||||
"#Guidelines">Guidelines</a> below.
|
||||
<ul>
|
||||
<li>
|
||||
<a href="#Design_and_Programming">Design and Programming</a>
|
||||
</li>
|
||||
<li>
|
||||
|
||||
<a href="#Directory_structure">Directory Structure</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#Documentation">Documentation</a>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>The author must be willing to participate in discussions on the mailing
|
||||
list, and to refine the library accordingly.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
<h3 align="left">
|
||||
<a name="License" id="License">License</a> requirements
|
||||
</h3>
|
||||
<p>
|
||||
The preferred way to meet the license requirements is to use the <a href=
|
||||
"../LICENSE_1_0.txt">Boost Software License</a>. See <a href=
|
||||
"license_info.html">license information</a>. If for any reason you do not
|
||||
intend to use the Boost Software License, please discuss the issues on the
|
||||
Boost <a href="mailing_lists.htm#main">developers mailing list</a> first.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The license requirements:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Must be simple to read and understand.
|
||||
</li>
|
||||
<li>Must grant permission without fee to copy, use and modify the software
|
||||
for any use (commercial and non-commercial).
|
||||
</li>
|
||||
<li>Must require that the license appear on all copies of the software
|
||||
source code.
|
||||
</li>
|
||||
<li>Must not require that the license appear with executables or other
|
||||
binary uses of the library.
|
||||
</li>
|
||||
|
||||
<li>Must not require that the source code be available for execution or
|
||||
other binary uses of the library.
|
||||
</li>
|
||||
<li>May restrict the use of the name and description of the library to the
|
||||
standard version found on the Boost web site.
|
||||
</li>
|
||||
</ul>
|
||||
<h3 align="left">
|
||||
<a name="Portability" id="Portability">Portability</a> requirements
|
||||
</h3>
|
||||
<ul>
|
||||
|
||||
<li>
|
||||
<p align="left">
|
||||
A library's interface must portable and not restricted to a particular
|
||||
compiler or operating system.
|
||||
</p>
|
||||
</li>
|
||||
<li>
|
||||
<p align="left">
|
||||
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).
|
||||
</p>
|
||||
|
||||
</li>
|
||||
<li>
|
||||
<p align="left">
|
||||
There is no requirement that a library run on C++ compilers which do
|
||||
not conform to the ISO standard.
|
||||
</p>
|
||||
</li>
|
||||
<li>
|
||||
<p align="left">
|
||||
|
||||
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 <a href=
|
||||
"../libs/config/config.htm">configuration header</a> is the preferred
|
||||
mechanism for working around compiler deficiencies.
|
||||
</p>
|
||||
</li>
|
||||
</ul>
|
||||
<p align="left">
|
||||
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.
|
||||
</p>
|
||||
<h3 align="left">
|
||||
<a name="Ownership" id="Ownership">Ownership</a>
|
||||
</h3>
|
||||
<p align="left">
|
||||
Are you sure you own the library you are thinking of
|
||||
submitting? "How to Copyright Software" by MJ Salone, Nolo
|
||||
Press, 1990 says:
|
||||
</p>
|
||||
|
||||
<blockquote>
|
||||
<p align="left">
|
||||
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.
|
||||
</p>
|
||||
</blockquote>
|
||||
<p align="left">
|
||||
Place a copyright notice in all the important files you submit. Boost won't
|
||||
accept libraries without clear copyright information.
|
||||
</p>
|
||||
|
||||
<h2 align="left">
|
||||
<a name="Guidelines" id="Guidelines">Guidelines</a>
|
||||
</h2>
|
||||
<p align="left">
|
||||
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.
|
||||
</p>
|
||||
<h3>
|
||||
<a name="Design_and_Programming" id="Design_and_Programming">Design and
|
||||
Programming</a>
|
||||
|
||||
</h3>
|
||||
<ul>
|
||||
<li>Aim first for clarity and correctness; optimization should be only a
|
||||
secondary concern in most Boost libraries.
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>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.
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
|
||||
<li>Headers should be good neighbors. See the <a href="header.htm">header
|
||||
policy</a>. See <a href="#Naming_consistency">Naming consistency</a>.
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>Follow quality programming practices. See, for example, "Effective C++"
|
||||
2nd Edition, and "More Effective C++", both by Scott Meyers, published by
|
||||
Addison Wesley.
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
|
||||
<li>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 <a href="library_reuse.htm">Library
|
||||
reuse</a>.
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>Read <a href="imp_vars.htm">Implementation Variation</a> to see how to
|
||||
supply performance, platform, or other implementation variations.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
<ul>
|
||||
<li>Read the <a href="separate_compilation.html">guidelines for libraries
|
||||
with separate source</a> to see how to ensure that compiled link libraries
|
||||
meet user expectations.
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>Use the naming conventions of the C++ Standard Library (See <a href=
|
||||
"#Naming">Naming conventions rationale</a>):<br>
|
||||
|
||||
|
||||
<ul>
|
||||
<li>Names (except as noted below) should be all lowercase, with words
|
||||
separated by underscores.
|
||||
</li>
|
||||
<li>Acronyms should be treated as ordinary names (e.g.
|
||||
<code>xml_parser</code> instead of <code>XML_parser</code>).
|
||||
</li>
|
||||
<li>Template parameter names begin with an uppercase letter.
|
||||
</li>
|
||||
|
||||
<li>Macro (gasp!) names all uppercase and begin with BOOST_.
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>Choose meaningful names - explicit is better than implicit, and
|
||||
readability counts. There is a strong preference for clear and descriptive
|
||||
names, even if lengthy.
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
|
||||
<li>Use exceptions to report errors where appropriate, and write code that
|
||||
is safe in the face of exceptions.
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>Avoid exception-specifications. See <a href="#Exception-specification">
|
||||
exception-specification rationale</a>.
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
|
||||
<li>Provide sample programs or confidence tests so potential users can see
|
||||
how to use your library.
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>Provide a regression test program or programs which follow the
|
||||
<a href="test_policy.htm">Test Policies and Protocols</a>.
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>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:
|
||||
<ul>
|
||||
|
||||
<li>Use fixed-width fonts. See <a href="#code_fonts">fonts
|
||||
rationale</a>.
|
||||
</li>
|
||||
<li>Use spaces rather than tabs. See <a href="#Tabs">tabs
|
||||
rationale</a>.
|
||||
</li>
|
||||
<li>Limit line lengths to 80 characters.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>End all documentation files (HTML or otherwise) with a copyright
|
||||
message and a licensing message. See <a href="license_info.html">license
|
||||
information</a> page for the preferred form.
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>Begin all source files (including programs, headers, scripts, etc.)
|
||||
with:<br>
|
||||
|
||||
|
||||
<ul>
|
||||
<li>A comment line describing the contents of the file.<br>
|
||||
|
||||
</li>
|
||||
<li>Comments describing copyright and licensing: again, the preferred
|
||||
form is indicated in the <a href="license_info.html">license
|
||||
information</a> page<br>
|
||||
|
||||
<br>
|
||||
Note that developers should not provide a copy of
|
||||
<code>LICENSE_1_0.txt</code> with their libraries: Boost
|
||||
distributions already include a copy in the Boost root directory.<br>
|
||||
|
||||
</li>
|
||||
<li>A comment line referencing your library on the Boost web site. For
|
||||
example:<br>
|
||||
<br>
|
||||
|
||||
<code>// See http://www.boost.org/libs/foo/ for library home
|
||||
page.</code><br>
|
||||
<br>
|
||||
where <code>foo</code> 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.
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
<ul>
|
||||
<li>Make sure your code compiles in the presence of the <code>min()</code>
|
||||
and <code>max()</code> macros. Some platform headers define
|
||||
<code>min()</code> and <code>max()</code> macros which cause some common
|
||||
C++ constructs to fail to compile. Some simple tricks can protect your code
|
||||
from inappropriate macro substitution:<br>
|
||||
|
||||
|
||||
<ul>
|
||||
<li>If you want to call <code>std::min()</code> or
|
||||
<code>std::max()</code>:<br>
|
||||
|
||||
<ul>
|
||||
<li>If you do not require argument-dependent look-up, use
|
||||
<code>(std::min)(a,b)</code>.
|
||||
</li>
|
||||
|
||||
<li style="list-style: none">
|
||||
<br>
|
||||
</li>
|
||||
<li>If you do require argument-dependent look-up, you should:
|
||||
</li>
|
||||
<li style="list-style: none">
|
||||
<br>
|
||||
<ul>
|
||||
<li>
|
||||
|
||||
<code>#include <boost/config.hpp></code>
|
||||
</li>
|
||||
<li>Use <code>BOOST_USING_STD_MIN();</code> to bring
|
||||
<code>std::min()</code> into the current scope.
|
||||
</li>
|
||||
<li>Use <code>min BOOST_PREVENT_MACRO_SUBSTITUTION
|
||||
(a,b);</code> to make an argument-dependent call to
|
||||
<code>min(a,b)</code>.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li style="list-style: none">
|
||||
<br>
|
||||
</li>
|
||||
<li>If you want to call
|
||||
<code>std::numeric_limits<int>::max()</code>, use
|
||||
<code>(std::numeric_limits<int>::max)()</code> instead.
|
||||
</li>
|
||||
|
||||
<li style="list-style: none">
|
||||
<br>
|
||||
</li>
|
||||
<li>If you want to call a <code>min()</code> or <code>max()</code>
|
||||
member function, instead to doing <code>obj.min()</code>, use
|
||||
<code>(obj.min)()</code>.<br>
|
||||
|
||||
</li>
|
||||
<li style="list-style: none">
|
||||
<br>
|
||||
</li>
|
||||
<li>If you want to declare or define a function or a member function
|
||||
named <code>min</code> or <code>max</code>, then you must use the
|
||||
<code>BOOST_PREVENT_MACRO_SUBSTITUTION</code> macro. Instead of writing
|
||||
<code>int min() { return 0; }</code> you should write <code>int min
|
||||
BOOST_PREVENT_MACRO_SUBSTITUTION () { return 0; }</code><br>
|
||||
|
||||
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.<br>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<h3>
|
||||
<a name="Directory_structure" id="Directory_structure">Directory
|
||||
Structure</a> and Filenames
|
||||
</h3>
|
||||
|
||||
<ul>
|
||||
<li>File and directory names must contain only <b>lowercase</b> ASCII
|
||||
letters , numbers, underscores, and a period. Leading character must
|
||||
be alphabetic. Maximum length 31. Only a single period is permitted.
|
||||
These requirements ensure file and directory names are relatively portable.
|
||||
</li>
|
||||
<li>Files intended to be processed by a C++ compiler as part of a
|
||||
translation unit should have <b>a three-letter filename extension ending in
|
||||
"pp"</b>. Other files should <i>not</i> use extensions ending in "pp". This
|
||||
convention makes it easy to identify all of the C++ source in Boost.
|
||||
</li>
|
||||
|
||||
<li>All libraries have at their highest level a primary directory named for
|
||||
the particular library. See <a href="#Naming_consistency">Naming
|
||||
consistency</a>. The primary directory may have sub-directories.
|
||||
</li>
|
||||
<li>For very simple libraries implemented entirely within the library
|
||||
header, all files go in the primary directory (except headers, which go in
|
||||
the boost header directory).
|
||||
</li>
|
||||
</ul>
|
||||
<blockquote>
|
||||
<p>
|
||||
<b>Boost standard sub-directory names</b>
|
||||
|
||||
</p>
|
||||
<table border="1" cellpadding="5">
|
||||
<tr>
|
||||
<td>
|
||||
<b>Sub-directory</b>
|
||||
</td>
|
||||
<td>
|
||||
<b>Contents</b>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
<b>Required</b>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<code>build</code>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
Library build files such as a Jamfile.
|
||||
</td>
|
||||
<td>
|
||||
If any build files.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
<code>doc</code>
|
||||
</td>
|
||||
<td>
|
||||
Documentation (HTML) files.
|
||||
</td>
|
||||
<td>
|
||||
If several doc files.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>
|
||||
<code>example</code>
|
||||
</td>
|
||||
<td>
|
||||
Sample program files.
|
||||
</td>
|
||||
<td>
|
||||
If several sample files.
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<code>src</code>
|
||||
</td>
|
||||
<td>
|
||||
Source files which must be compiled to build the library.
|
||||
</td>
|
||||
|
||||
<td>
|
||||
If any source files.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<code>test</code>
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Regression or other test programs or scripts.
|
||||
</td>
|
||||
<td>
|
||||
If several test files.
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
</blockquote>
|
||||
<h4>
|
||||
<a name="Redirection" id="Redirection">Redirection</a>
|
||||
|
||||
</h4>
|
||||
<p>
|
||||
The primary directory should always contain a file named index.html (or
|
||||
index.htm). Authors have requested this so that they can publish URL's in
|
||||
the form <i>http://www.boost.org/libs/lib-name</i> 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.
|
||||
</p>
|
||||
<p>
|
||||
If the documentation is in a doc sub-directory, the primary directory
|
||||
index.html file should just do an automatic redirection to the doc
|
||||
subdirectory:
|
||||
</p>
|
||||
<blockquote>
|
||||
|
||||
<pre>
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="refresh" content="0; URL=doc/index.html">
|
||||
</head>
|
||||
<body>
|
||||
Automatic redirection failed, please go to
|
||||
<a href="doc/index.html">doc/index.html</a>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
</pre>
|
||||
</blockquote>
|
||||
<h3>
|
||||
<a name="Naming_consistency">Naming consistency</a>
|
||||
</h3>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
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".
|
||||
</p>
|
||||
<ul>
|
||||
<li>The library's primary directory (in parent <i>boost-root/libs</i>) is
|
||||
given that same name. For example,
|
||||
<i>boost-root/libs/filesystem</i>.<br>
|
||||
|
||||
|
||||
</li>
|
||||
<li>The library's primary header directory (in parent
|
||||
<i>boost-root/boost</i>) is given that same name. For example,
|
||||
<i>boost-root/boost/filesystem</i>.<br>
|
||||
|
||||
</li>
|
||||
<li>The library's primary namespace (in parent <i>::boost</i>) is given
|
||||
that same name, except when there's a component with that name (e.g.,
|
||||
<i>boost::tuple</i>), in which case the namespace name is pluralized. For
|
||||
example, <i>::boost::filesystem</i>.
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
<p>
|
||||
When documenting Boost libraries, follow these conventions (see also the
|
||||
following section of this document):
|
||||
</p>
|
||||
<ul>
|
||||
<li>The library name is set in roman type.
|
||||
</li>
|
||||
<li>The library name is capitalized.
|
||||
</li>
|
||||
<li>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".
|
||||
</li>
|
||||
|
||||
<li>The word "library" is not part of the library name and is therefore
|
||||
lowercased.
|
||||
</li>
|
||||
</ul>
|
||||
<p>
|
||||
Here are a few examples of how to apply these conventions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Boost.Bind was written by Peter Dimov.
|
||||
</li>
|
||||
<li>The Boost Bind library was written by Peter Dimov.
|
||||
</li>
|
||||
|
||||
<li>I regularly use Bind, a Boost library written by Peter Dimov.
|
||||
</li>
|
||||
</ul>
|
||||
<h3>
|
||||
<a name="Documentation" id="Documentation">Documentation</a>
|
||||
</h3>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
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 not acceptable. The documentation entry point
|
||||
should always be a file named index.html or index.htm; see <a href=
|
||||
"#Redirection">Redirection</a>.
|
||||
</p>
|
||||
<p>
|
||||
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?
|
||||
</p>
|
||||
<p>
|
||||
Appropriate topics for documentation often include:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>General introduction to the library.
|
||||
</li>
|
||||
<li>Description of each class.
|
||||
</li>
|
||||
<li>Relationship between classes.
|
||||
</li>
|
||||
<li>For each function, as applicable, description, requirements
|
||||
(preconditions), effects, post-conditions, returns, and throws.
|
||||
</li>
|
||||
<li>Discussion of error detection and recovery strategy.
|
||||
</li>
|
||||
|
||||
<li>How to use including description of typical uses.
|
||||
</li>
|
||||
<li>How to compile and link.
|
||||
</li>
|
||||
<li>How to test.
|
||||
</li>
|
||||
<li>Version or revision history.
|
||||
</li>
|
||||
<li>Rationale for design decisions. See <a href=
|
||||
"#Rationale">Rationale rationale</a>.
|
||||
</li>
|
||||
|
||||
<li>Acknowledgements. See <a href="#Acknowledgements">Acknowledgments
|
||||
rationale.</a>
|
||||
</li>
|
||||
</ul>
|
||||
<p>
|
||||
If you need more help with how to write documentation you can check out the
|
||||
article on <a href="writingdoc/index.html">Writing Documentation for
|
||||
Boost</a>.
|
||||
</p>
|
||||
|
||||
<h2>
|
||||
<a name="Rationale" id="Rationale">Rationale</a>
|
||||
</h2>
|
||||
<p>
|
||||
Rationale for some of the requirements and guidelines follows.
|
||||
</p>
|
||||
<hr>
|
||||
<h3>
|
||||
<a name="Exception-specification" id=
|
||||
"Exception-specification">Exception-specification</a> rationale
|
||||
</h3>
|
||||
|
||||
<p>
|
||||
Exception specifications [ISO 15.4] are sometimes coded to indicate what
|
||||
exceptions may be thrown, or because the programmer hopes they will
|
||||
improved performance. But consider the following member from a smart
|
||||
pointer:
|
||||
</p>
|
||||
<pre>
|
||||
T& operator*() const throw() { return *ptr; }
|
||||
</pre>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
<p>
|
||||
Although initially appealing, an exception-specification tends to have
|
||||
consequences that require <b>very</b> 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.
|
||||
</p>
|
||||
<p>
|
||||
|
||||
A non-inline function is the one place a "throws nothing"
|
||||
exception-specification may have some benefit with some compilers.
|
||||
</p>
|
||||
<hr>
|
||||
<h3>
|
||||
<a name="Naming" id="Naming">Naming</a> conventions rationale
|
||||
</h3>
|
||||
<p>
|
||||
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:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>Naming conventions are contentious, and although several are widely
|
||||
used, no one style predominates.
|
||||
</li>
|
||||
<li>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.
|
||||
</li>
|
||||
<li>Once a library settles on a particular convention, a vast majority of
|
||||
stakeholders want that style to be consistently used.
|
||||
</li>
|
||||
</ul>
|
||||
<hr>
|
||||
<h3>
|
||||
|
||||
Source <a name="code_fonts" id="code_fonts">code fonts</a> rationale
|
||||
</h3>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
<hr>
|
||||
<h3>
|
||||
<a name="Tabs" id="Tabs">Tabs</a> rationale
|
||||
</h3>
|
||||
|
||||
<p>
|
||||
Tabs are banned because of the practical problems caused by tabs in
|
||||
multi-developer projects like Boost, rather than any dislike in principle.
|
||||
See <a href="mailing_lists.htm#archive">mailing list archives</a>. 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.
|
||||
</p>
|
||||
<hr>
|
||||
<h3>
|
||||
ECMAScript/<a name="JavaScript" id="JavaScript">JavaScript</a> rationale
|
||||
</h3>
|
||||
|
||||
<p>
|
||||
Before the 1.29.0 release, two Boost libraries added ECMAScript/JavaScript
|
||||
documentation. Controversy followed (see <a href=
|
||||
"mailing_lists.htm#archive">mailing list archives</a>), and the developers
|
||||
were asked to remove the ECMAScript/JavaScript. Reasons given for banning
|
||||
included:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Incompatible with some older browsers and some text based browsers.
|
||||
</li>
|
||||
<li>Makes printing docs pages difficult.
|
||||
</li>
|
||||
<li>Often results in really bad user interface design.
|
||||
</li>
|
||||
|
||||
<li>"It's just annoying in general."
|
||||
</li>
|
||||
<li>Would require Boost to test web pages for ECMAScript/JavaScript
|
||||
compliance.
|
||||
</li>
|
||||
<li>Makes docs maintenance by other than the original developer more
|
||||
difficult.
|
||||
</li>
|
||||
</ul>
|
||||
<hr>
|
||||
<h3>
|
||||
<a name="Rationale_rationale" id="Rationale_rationale">Rationale
|
||||
rationale</a>
|
||||
|
||||
</h3>
|
||||
<p>
|
||||
Rationale is defined as "The fundamental reasons for something; basis" by
|
||||
the American Heritage Dictionary.
|
||||
</p>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
<p>
|
||||
Rationale is fairly easy to provide at the time decisions are made, but
|
||||
very hard to accurately recover even a short time later.
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
<h3>
|
||||
<a name="Acknowledgements" id="Acknowledgements">Acknowledgements</a>
|
||||
rationale
|
||||
</h3>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
<p>
|
||||
Revised
|
||||
<!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan -->
|
||||
04 November, 2003<!--webbot bot="Timestamp" endspan i-checksum="39359" -->
|
||||
</p>
|
||||
<p>
|
||||
© <a name="Copyright" id="Copyright">Copyright</a> Beman Dawes 2003.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Distributed under the Boost Software License, Version 1.0. (See
|
||||
accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy
|
||||
at <a href=
|
||||
"http://www.boost.org/LICENSE_1_0.txt">www.boost.org/LICENSE_1_0.txt</a>)
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
@ -1,75 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<meta http-equiv="Content-Language" content="en-us">
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
||||
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
||||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||||
<title>Boost Library Reuse</title>
|
||||
</head>
|
||||
|
||||
<body bgcolor="#FFFFFF" text="#000000">
|
||||
|
||||
<table border="1" bgcolor="#007F7F" cellpadding="2">
|
||||
<tr>
|
||||
<td bgcolor="#FFFFFF"><img src="../boost.png" alt="boost.png (6897 bytes)" width="277" height="86"></td>
|
||||
<td><a href="../index.htm"><font face="Arial" color="#FFFFFF"><big>Home</big></font></a></td>
|
||||
<td><a href="../libs/libraries.htm"><font face="Arial" color="#FFFFFF"><big>Libraries</big></font></a></td>
|
||||
<td><a href="../people/people.htm"><font face="Arial" color="#FFFFFF"><big>People</big></font></a></td>
|
||||
<td><a href="faq.htm"><font face="Arial" color="#FFFFFF"><big>FAQ</big></font></a></td>
|
||||
<td><a href="index.htm"><font face="Arial" color="#FFFFFF"><big>More</big></font></a></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>Boost Library reuse: cost versus benefit trade-offs</h1>
|
||||
<p>A Boost library <b>should not</b> use libraries other than Boost or the C++
|
||||
Standard Library.</p>
|
||||
<p>A Boost library <b>should</b> use other Boost Libraries or the C++ Standard
|
||||
Library, but only when the benefits outweigh the costs. </p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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).</p>
|
||||
<p><b>Example where another boost component should certainly be used:</b>
|
||||
boost::noncopyable (in <a href="../boost/utility.hpp">boost/utility.hpp</a>) 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.</p>
|
||||
<p><b>Example where a standard library component might possibly be used:</b>
|
||||
Providing diagnostic output as a debugging aid can be a nice feature for a
|
||||
library. Yet using Standard Library <iostream> can involves a lot of
|
||||
additional cost, particularly if <iostream> is unlikely to be use
|
||||
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.</p>
|
||||
<p><b>Example where another boost component should not be used:</b> 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.</p>
|
||||
<hr>
|
||||
<p>Revised <!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B %Y" startspan -->02 October 2003<!--webbot bot="Timestamp" endspan i-checksum="32277" --></p>
|
||||
<p>© Copyright Beman Dawes 2000</p>
|
||||
<p>Distributed under the Boost Software License, Version 1.0. (See
|
||||
accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy
|
||||
at <a href="http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>)</p>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
@ -1,280 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<meta http-equiv="Content-Language" content="en-us">
|
||||
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
||||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<title>Boost Software License Background</title>
|
||||
</head>
|
||||
|
||||
<body bgcolor="#FFFFFF">
|
||||
|
||||
<table summary="Navigational header"
|
||||
border="1" bgcolor="#007F7F" cellpadding="2">
|
||||
<tr>
|
||||
<td bgcolor="#FFFFFF"><img src="../boost.png" alt="boost.png (6897 bytes)" width="277" height="86"></td>
|
||||
<td><a href="../index.htm"><font face="Arial" color="#FFFFFF"><big>Home</big></font></a></td>
|
||||
<td><a href="../libs/libraries.htm"><font face="Arial" color="#FFFFFF"><big>Libraries</big></font></a></td>
|
||||
<td><a href="../people/people.htm"><font face="Arial" color="#FFFFFF"><big>People</big></font></a></td>
|
||||
<td><a href="faq.htm"><font face="Arial" color="#FFFFFF"><big>FAQ</big></font></a></td>
|
||||
<td><a href="index.htm"><font face="Arial" color="#FFFFFF"><big>More</big></font></a></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>Information about the <a href="../LICENSE_1_0.txt">Boost Software License</a> </h1>
|
||||
|
||||
<p><a href="../LICENSE_1_0.txt">License text</a><br>
|
||||
<a href="#Introduction">Introduction</a><br>
|
||||
<a href="#History">History</a><br>
|
||||
<a href="#Rationale">Rationale</a><br>
|
||||
<a href="#FAQ">FAQ</a><br>
|
||||
<a href="#Transition">Transition</a><br>
|
||||
<a href="#Acknowledgements">Acknowledgements</a></p>
|
||||
|
||||
<h2><a name="Introduction">Introduction</a></h2>
|
||||
|
||||
<p>The <a href="../LICENSE_1_0.txt">Boost Software License</a>
|
||||
specifies the terms and conditions of use for those Boost libraries
|
||||
that it covers.</p>
|
||||
|
||||
<p>Currently, some Boost libraries have their own licenses. The hope is that
|
||||
eventually all Boost libraries will be covered by the Boost Software
|
||||
License. In the meantime, <b>all</b> libraries comply with the <a
|
||||
href="#requirements">Boost License requirements</a>.</p>
|
||||
|
||||
<h2><a name="History">History</a></h2>
|
||||
|
||||
<p>As Boost grew, it became unmanageable for each Boost file to have
|
||||
its own license. Users complained that each license needed to be reviewed, and that
|
||||
reviews were difficult or impossible if Boost libraries contained many different licenses.
|
||||
Boost moderators and maintainers spent excessive time dealing with license
|
||||
issues. Boost developers often copied existing licenses without actually knowing
|
||||
if the license wording met legal needs.</p>
|
||||
<p>To clarify these licensing issues, the Boost moderators asked for help from
|
||||
the <a href="http://cyber.law.harvard.edu">Berkman Center for Internet & Society</a>
|
||||
at Harvard Law School, Cambridge, Massachusetts, USA. It was requested that a
|
||||
single Boost license be developed that met the traditional requirements that Boost licenses, particularly:</p>
|
||||
|
||||
<a name="requirements"></a>
|
||||
<ul>
|
||||
<li>Must be simple to read and understand. </li>
|
||||
<li>Must grant permission without fee to copy, use and modify the software for
|
||||
any use (commercial and non-commercial). </li>
|
||||
<li>Must require that the license appear with all copies [including
|
||||
redistributions] of the software source code. </li>
|
||||
<li>Must not require that the license appear with executables or other binary
|
||||
uses of the library. </li>
|
||||
<li>Must not require that the source code be available for execution or other
|
||||
binary uses of the library. </li>
|
||||
</ul>
|
||||
|
||||
<p>Additionally, other common open source licenses were studied to see what
|
||||
additional issues were being treated, and additions representing good legal
|
||||
practice were also requested. The result is the <a href="../LICENSE_1_0.txt">Boost
|
||||
Software License</a>.</p>
|
||||
|
||||
<h2><a name="Rationale">Rationale</a></h2>
|
||||
|
||||
<p>The following rationale was provided by Devin Smith, the
|
||||
lawyer who wrote the Boost Software License. It has been edited slightly for
|
||||
brevity. Editorial additions are shown in square brackets.</p>
|
||||
|
||||
<h3>Benefit of Common Software License</h3>
|
||||
<p>If one of Boost's goals is to ease use and adoption of the various
|
||||
libraries made available by Boost, it does make sense to try to
|
||||
standardize the licenses under which the libraries are made available to
|
||||
users. (I make some recommendations about a possible short-form license
|
||||
below.)</p>
|
||||
<p>[Standardizing the license will not] necessarily address the issue of satisfying
|
||||
corporate licensees. Each corporation will have its own concerns, based
|
||||
on their own experiences with software licensing and distribution and,
|
||||
if they're careful, will want to carefully review each license, even if
|
||||
they've been told that they're all standard. I would expect that,
|
||||
unless we're remarkably brilliant (or lucky) in drafting the standard
|
||||
Boost license, the standard license won't satisfy the legal departments
|
||||
of all corporations. I imagine that some will, for instance, absolutely
|
||||
insist that licensors provide a warranty of title and provide
|
||||
indemnification for third-party intellectual property infringement
|
||||
claims. Others may want functional warranties. (If I were advising the
|
||||
corporations, I would point out that they're not paying anything for the
|
||||
code and getting such warranties from individual programmers, who
|
||||
probably do not have deep pockets, is not that valuable anyway, but
|
||||
other lawyers may disagree.)</p>
|
||||
<p>But this can be addressed, not by trying to craft the perfect standard
|
||||
license, but by informing the corporations that they can, if they don't like the
|
||||
standard license, approach the authors to negotiate a different, perhaps even
|
||||
paid, license.</p>
|
||||
<p>One other benefit of adopting a standard license is to help ensure that
|
||||
the license accomplishes, from a legal perspective, what the authors
|
||||
intend. For instance, many of the [original] licenses for the libraries available
|
||||
on boost.org do not disclaim the warranty of title, meaning that the
|
||||
authors could, arguably, be sued by a user if the code infringes the
|
||||
rights of a third party and the user is sued by that third party. I
|
||||
think the authors probably want to disclaim this kind of liability.</p>
|
||||
<h3>Short-Form License</h3>
|
||||
<p>Without in anyway detracting from the draft license that's been
|
||||
circulated [to Boost moderators], I'd like to propose an alternative "short-form" license that
|
||||
Boost could have the library authors adopt. David [Abrahams] has expressed a
|
||||
desire to keep things as simple as possible, and to try to move away
|
||||
from past practice as little as possible, and this is my attempt at a
|
||||
draft.</p>
|
||||
<p>This license, which is very similar to the BSD license and the MIT
|
||||
license, should satisfy the Open Source Initiative's Open Source
|
||||
Definition: (i) the license permits free redistribution, (ii) the
|
||||
distributed code includes source code, (iii) the license permits the
|
||||
creation of derivative works, (iv) the license does not discriminate
|
||||
against persons or groups, (v) the license does not discriminate against
|
||||
fields of endeavor, (vi) the rights apply to all to whom the program is
|
||||
redistributed, (vii) the license is not specific to a product, and (viii) the
|
||||
license is technologically neutral (i.e., it does not [require] an explicit gesture of
|
||||
assent in order to establish a contract between licensor and licensee).</p>
|
||||
<p>This license grants all rights under the owner's copyrights (as well as an
|
||||
implied patent license), disclaims all liability for use of the code (including
|
||||
intellectual property infringement liability), and requires that all subsequent
|
||||
copies of the code [except machine-executable object code], including partial copies and derivative works, include the
|
||||
license.</p>
|
||||
|
||||
<h2><a name="FAQ">FAQ</a></h2>
|
||||
|
||||
<p><b>How should Boost programmers apply the license to source and
|
||||
header files?</b></p>
|
||||
|
||||
<p>Add a comment based on the following template, substituting
|
||||
appropriate text for the italicized portion:
|
||||
<br>
|
||||
<br>
|
||||
<pre>
|
||||
// Copyright <i>Joe Coder 2004 - 2006</i>.
|
||||
// Distributed under the Boost Software License, Version 1.0.
|
||||
// (See accompanying file LICENSE_1_0.txt or copy at
|
||||
// http://www.boost.org/LICENSE_1_0.txt)
|
||||
</pre>
|
||||
<br>
|
||||
Please leave an empty line before and after the above comment block.
|
||||
It is fine if the copyright and license messages are not on different lines; in
|
||||
no case there should be other intervening text. Do not include
|
||||
"All rights reserved" anywhere.<br>
|
||||
|
||||
<p>Other ways of licensing source files have been considered, but some
|
||||
of them turned out to unintentionally nullify legal elements of the
|
||||
license. Having fixed language for referring to the license helps
|
||||
corporate legal departments evaluate the boost distribution.
|
||||
Creativity in license reference language is strongly discouraged, but
|
||||
judicious changes in the use of whitespace are fine.
|
||||
|
||||
<p><b>How should the license be applied to documentation files, instead?</b></p>
|
||||
|
||||
<p>Very similarly to the way it is applied to source files: the user should
|
||||
see the very same text indicated in the template above, with the only difference
|
||||
that both the local and the web copy of LICENSE_1_0.txt should be linked to.
|
||||
Refer to the HTML source code of this page in case of doubt.
|
||||
|
||||
<p>Note that the location of the local LICENSE_1_0.txt needs to be indicated
|
||||
relatively to the position of your documentation file
|
||||
(<code>../LICENSE_1_0.txt</code>, <code>../../LICENSE_1_0.txt</code> etc.)</p>
|
||||
|
||||
<p><b>How is the Boost license different from the
|
||||
<a href="http://www.opensource.org/licenses/gpl-license.php">GNU General Public
|
||||
License (GPL)</a>?</b></p>
|
||||
|
||||
|
||||
<p>The Boost license permits the creation of derivative works for
|
||||
commercial or non-commercial use with no legal requirement to release
|
||||
your source code. Other differences include Boost not requiring
|
||||
reproduction of copyright messages for object code redistribution, and
|
||||
the fact that the Boost license is not "viral": if you
|
||||
distribute your own code along with some Boost code, the Boost license
|
||||
applies only to the Boost code (and modified versions thereof); you
|
||||
are free to license your own code under any terms you like. The GPL is
|
||||
also much longer, and thus may be harder to understand.</p>
|
||||
|
||||
<p><b>Why the phrase "machine-executable object code generated by a source
|
||||
language processor"?</b></p>
|
||||
|
||||
<p>To distinguish cases where we do not require reproduction of the copyrights
|
||||
and license, such as object libraries, shared libraries, and final program
|
||||
executables, from cases where reproduction is still required, such as
|
||||
distribution of self-extracting archives of source code or precompiled header
|
||||
files. More detailed wording was rejected as not being legally necessary, and
|
||||
reducing readability.</p>
|
||||
|
||||
<p><b>Why is the "disclaimer" paragraph of the license entirely in uppercase?</b></p>
|
||||
|
||||
<p>Capitalization of these particular provisions is a US legal mandate for
|
||||
consumer protection. (Diane Cabell)</p>
|
||||
|
||||
<p><b>Does the copyright and license cover interfaces too?</b></p>
|
||||
|
||||
<p>The conceptual interface to a library isn't covered. The particular
|
||||
representation expressed in the header is covered, as is the documentation,
|
||||
examples, test programs, and all the other material that goes with the library.
|
||||
A different implementation is free to use the same logical interface, however.
|
||||
Interface issues have been fought out in court several times; ask a lawyer for
|
||||
details.</p>
|
||||
|
||||
<p><b>Why doesn't the license prohibit the copyright holder from patenting the
|
||||
covered software?</b></p>
|
||||
|
||||
<p>No one who distributes their code under the terms of this license could turn
|
||||
around and sue a user for patent infringement. (Devin Smith)</p>
|
||||
|
||||
<p>Boost's lawyers were well aware of patent provisions in licenses like the GPL
|
||||
and CPL, and would have included such provisions in the Boost license if they
|
||||
were believed to be legally useful.</p>
|
||||
|
||||
<p><b>Why doesn't the copyright message say "All rights reserved"?</b></p>
|
||||
|
||||
<p>Devin Smith says "I don't think it belongs in the copyright notice for
|
||||
anything (software, electronic documentation, etc.) that is being licensed. It
|
||||
belongs in books that are sold where, in fact, all rights (e.g., to reproduce
|
||||
the book, etc.) are being reserved in the publisher or author. I think it
|
||||
shouldn't be in the BSD license."</p>
|
||||
|
||||
<p><b>Do I have to copyright/license trivial files?</b>
|
||||
|
||||
<p>Even a test file that just contains an empty <code>main()</code>
|
||||
should have a copyright. Files without copyrights make corporate
|
||||
lawyers nervous, and that's a barrier to adoption. The more of Boost
|
||||
is uniformly copyrighted and licensed, the less problem people will
|
||||
have with mounting a Boost release CD on a corporate server.
|
||||
|
||||
|
||||
<p><b>Can I use the Boost license for my own projects outside Boost?</b>
|
||||
|
||||
<p>Sure; there are no restrictions on the use of the license itself.
|
||||
|
||||
<h2><a name="Transition">Transition</a></h2>
|
||||
|
||||
<p>To ease the transition of the code base towards the new common
|
||||
license, several people decided to give a <a
|
||||
href="blanket-permission.txt">blanket permission</a> for all
|
||||
their contributions to use the new license. This hopefully helps
|
||||
maintainers to switch to the new license once the list contains enough
|
||||
names without asking over and over again for each change. Please
|
||||
consider adding your name to the list.</p>
|
||||
|
||||
<h2><a name="Acknowledgements">Acknowledgements</a></h2>
|
||||
<p>Dave Abrahams led the Boost effort to develop better licensing. The legal
|
||||
team was led by
|
||||
<a href="http://cyber.law.harvard.edu/people/cabell/index.html">Diane Cabell</a>,
|
||||
Director, Clinical Programs, <a href="http://cyber.law.harvard.edu">Berkman
|
||||
Center for Internet & Society</a>, Harvard Law School.
|
||||
<a href="http://www.nixonpeabody.com/attorneys_detail1.asp?ID=121">Devin Smith</a>, attorney, <a href="http://www.nixonpeabody.com/default.asp">
|
||||
Nixon Peabody LLP</a>, wrote the Boost License. Eva Chan, Harvard Law School,
|
||||
contributed analysis of Boost issues and drafts of various legal documents.
|
||||
Boost members reviewed drafts of the license. Beman Dawes wrote this web page.</p>
|
||||
<hr>
|
||||
<p>Revised
|
||||
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->27 August, 2004<!--webbot bot="Timestamp" endspan i-checksum="39365" --></p>
|
||||
|
||||
<p> © Copyright 2003-2004 Beman Dawes, Daniel Frey, David Abrahams.</p>
|
||||
<p> Distributed under the Boost Software License, Version 1.0.
|
||||
(See accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or
|
||||
copy at <a href="http://www.boost.org/LICENSE_1_0.txt">www.boost.org/LICENSE_1_0.txt</a>)
|
||||
</p>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
@ -1,403 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
|
||||
<html>
|
||||
<head>
|
||||
<title>Mailing Lists</title>
|
||||
<meta name="generator" content=
|
||||
"Microsoft FrontPage 5.0">
|
||||
<meta name="generator" content="Microsoft FrontPage 5.0">
|
||||
<meta name="generator" content="Microsoft FrontPage 5.0">
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
||||
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
||||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||||
<style type="text/css">
|
||||
@import ../boost.css
|
||||
.first {
|
||||
margin-top: 0 }
|
||||
|
||||
.last {
|
||||
margin-bottom: 0 }
|
||||
|
||||
div.attention, div.caution, div.danger, div.error, div.hint,
|
||||
div.important, div.note, div.tip, div.warning, div.admonition {
|
||||
margin: 2em ;
|
||||
border: medium outset ;
|
||||
padding: 1em }
|
||||
|
||||
div.attention p.admonition-title, div.caution p.admonition-title,
|
||||
div.danger p.admonition-title, div.error p.admonition-title,
|
||||
div.warning p.admonition-title {
|
||||
color: red ;
|
||||
font-weight: bold ;
|
||||
font-family: sans-serif }
|
||||
|
||||
div.hint p.admonition-title, div.important p.admonition-title,
|
||||
div.note p.admonition-title, div.tip p.admonition-title,
|
||||
div.admonition p.admonition-title {
|
||||
font-weight: bold ;
|
||||
font-family: sans-serif }
|
||||
</style>
|
||||
</head>
|
||||
|
||||
<body bgcolor="#FFFFFF" text="#000000">
|
||||
<table summary="Navigational header"
|
||||
border="1" bgcolor="#007F7F" cellpadding="2">
|
||||
<tr>
|
||||
<td bgcolor="#FFFFFF"><img src="../boost.png" alt=
|
||||
"boost.png (6897 bytes)" width="277" height="86"></td>
|
||||
|
||||
<td><a href="../index.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>Home</big></font></a></td>
|
||||
|
||||
<td><a href="../libs/libraries.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>Libraries</big></font></a></td>
|
||||
|
||||
<td><a href="../people/people.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>People</big></font></a></td>
|
||||
|
||||
<td><a href="faq.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>FAQ</big></font></a></td>
|
||||
|
||||
<td><a href="index.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>More</big></font></a></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>Boost Mailing Lists and other resources</h1>
|
||||
|
||||
<p>The mailing lists are the heart of the Boost community. You may
|
||||
read the lists via full-content email, email digests, or via newsgroup
|
||||
reader.</p>
|
||||
|
||||
<p>Hosting for the mailing lists is donated by the <a href=
|
||||
"http://www.osl.iu.edu/">Open Systems Lab at Indiana University</a>.</p>
|
||||
|
||||
<p>Access to Boost mailing lists via newsgroup (NNTP) is contributed by
|
||||
<a href="http://www.gmane.org/">GMANE</a>.</p><a name="gmane_post" id=
|
||||
"gmane_post"></a><a name="important_notes" id="important_notes"></a>
|
||||
|
||||
<div class="admonition-note admonition">
|
||||
<p class="first admonition-title">Before Posting</p>
|
||||
|
||||
<p class="last">
|
||||
|
||||
<b>Read the <a href="discussion_policy.htm">Discussion Policy and
|
||||
Guide to Effective Posting</a>.</b> Doing so will help you
|
||||
to ensure that your post is read by the people who can help you
|
||||
and received in the spirit in which it was intended.
|
||||
|
||||
<p>
|
||||
<b>Subscribe your posting address.</b> As an anti-spam
|
||||
measure, postings to most Boost mailing lists will only be
|
||||
accepted if the posting's "From:" header contains an email
|
||||
address that is subscribed to the list. If you try to post from
|
||||
an address that isn't subscribed, you will probably get a
|
||||
message that says:</p>
|
||||
|
||||
<blockquote>
|
||||
<tt>You are not allowed to post to this mailing list, and your message
|
||||
has been automatically rejected. If you think that your messages are
|
||||
being rejected in error, contact the mailing list owner at</tt> <i>list
|
||||
administrator's email address</i>.
|
||||
</blockquote>If you need to post from multiple email addresses, you
|
||||
should subscribe each one separately. You can configure your subscription
|
||||
settings for any address to disable mail delivery via each mailing list's
|
||||
web interface.
|
||||
|
||||
<p>Even postings made through the <a href=
|
||||
"http://www.gmane.org">GMane</a> news server need to be made from
|
||||
subscribed addresses because GMane simply forwards your postings
|
||||
on to the appropriate email list. Don't be fooled by GMane's
|
||||
authentication message that says "you are now authorized to post
|
||||
to this list" after you answer its autogenerated mail; only
|
||||
subscribed addresses may post.</p>
|
||||
|
||||
</div>
|
||||
|
||||
<dl>
|
||||
<dt><a href="#users">Boost Users</a> list
|
||||
|
||||
<dt><a href="#main">Boost developers</a> list</dt>
|
||||
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><a href="#archive">Archives</a> for the Boost developers
|
||||
list</dt>
|
||||
</dl>
|
||||
</dd>
|
||||
|
||||
<dt><a href="#announce">Boost Announce</a> list</dt>
|
||||
|
||||
<dt><a href="#interest">Boost Interest</a> list</dt>
|
||||
|
||||
<dt><a href="#projects">Project-Specific</a> lists</dt>
|
||||
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><a href="#jamboost">Boost.Build</a> list</dt>
|
||||
|
||||
<dt><a href="#cplussig">Python C++-Sig</a> (for Boost.Python)</dt>
|
||||
|
||||
<dt><a href="#langbinding">Language Binding</a> (for generalized C++
|
||||
bindings)</dt>
|
||||
|
||||
<dt><a href="#spirit">Boost.Spirit</a> lists</dt>
|
||||
|
||||
<dt><a href="https://lists.sourceforge.net/lists/listinfo/boost-docs">Boost.Documentation</a> list</dt>
|
||||
|
||||
<dt><a href="#testing">Testing</a> list (about regression-testing the
|
||||
boost libraries, not for the Boost.Test library specifically)</dt>
|
||||
|
||||
<dt><a href="#ublas">Boost.uBlas (numerics)</a> list</dt>
|
||||
|
||||
<dt><a href="#thread">Boost.Thread</a> list</dt>
|
||||
</dl>
|
||||
</dd>
|
||||
|
||||
<dt><a href="#sandbox">Boost Sandbox</a></dt>
|
||||
|
||||
<dt><a href="#IRC">#boost IRC channel</a></dt>
|
||||
</dl>
|
||||
|
||||
<h2>Boost <a name="users" id="users">Users</a> mailing list (also available
|
||||
via newsgroup)</h2>
|
||||
|
||||
<p>This list is oriented toward casual users of the Boost
|
||||
libraries. It is a good place to start if you are having
|
||||
trouble getting started with Boost or its individual libraries. Feel
|
||||
free to post both "newbie" and more challenging questions, but
|
||||
please check first to see if there's an
|
||||
appropriate <a href="#projects">Project-Specific</a> list; you'll
|
||||
often get better answers in a forum dedicated to your problem
|
||||
area. This list is relatively
|
||||
low volume (less than 500 per month). Subscribe or unsubscribe
|
||||
at the <a href=
|
||||
"http://lists.boost.org/mailman/listinfo.cgi/boost-users">Boost Users list
|
||||
home page</a>.
|
||||
</p>
|
||||
|
||||
<p>For those who prefer to participate via an NNTP (<a name=
|
||||
"users_newsgroup" id="users_newsgroup">newsgroup</a>) interface, a gateway
|
||||
to the Boost Users mailing list is available at <a href=
|
||||
"news://news.gmane.org/gmane.comp.lib.boost.user">news://news.gmane.org/gmane.comp.lib.boost.user</a>.
|
||||
You can also browse <a href=
|
||||
"http://news.gmane.org/thread.php?group=gmane.comp.lib.boost.user">Gmane's
|
||||
searchable archive</a>.</p>
|
||||
|
||||
<h2><a name="main" id="main">Boost</a> developers mailing list (also
|
||||
available via newsgroup)</h2>
|
||||
|
||||
<p>This is the main Boost mailing list. It is high volume (over 1000
|
||||
messages per month), very technical, and oriented toward Boost library
|
||||
developers. It is also read by many other members interested in watching
|
||||
the Boost library development process. Virtually all Boost decisions,
|
||||
major or minor, technical or otherwise, are reached via public discussion
|
||||
on this mailing list. It is where the formal reviews of proposed
|
||||
libraries take place. Subscribe or unsubscribe at <a href=
|
||||
"http://lists.boost.org/mailman/listinfo.cgi/boost">http://lists.boost.org/mailman/listinfo.cgi/boost</a>.</p>
|
||||
|
||||
<p>When we talk about the "members of Boost", we are talking about those
|
||||
signed up for this main mailing list.</p>
|
||||
|
||||
<p>For those who prefer to participate via an NNTP (<a name="newsgroup" id=
|
||||
"newsgroup">newsgroup</a>) interface, a gateway to the Boost mailing list
|
||||
is available at <a href=
|
||||
"news://news.gmane.org/gmane.comp.lib.boost.devel">news://news.gmane.org/gmane.comp.lib.boost.devel</a>.
|
||||
|
||||
<p>Preliminary libraries under discussion are available from the <a href=
|
||||
"http://boost-consulting.com/vault/">Vault</a>.</p>
|
||||
|
||||
<h3><a name="archive" id="archive">Archives</a> for Boost developers
|
||||
list</h3>
|
||||
|
||||
<p>Archives of Boost messages include the
|
||||
<a href="http://news.gmane.org/thread.php?group=gmane.comp.lib.boost.devel">Boost
|
||||
GMane NNTP Archive</a>, <a href=
|
||||
"http://www.mail-archive.com/boost%40lists.boost.org/">The Mail
|
||||
Archive</a>, <a
|
||||
href="http://archives.free.net.ph/list/boost.en.html">The Free
|
||||
Network Group</a>, and of course there is a Google search link for our <a href=
|
||||
"http://lists.boost.org/Archives/boost/">MailMan Archive</a> on
|
||||
<a href="../index.htm">our home page</a>.
|
||||
|
||||
<h2>Boost <a name="announce" id="announce">Announce</a> mailing list</h2>
|
||||
|
||||
<p>This is an announce-only list for notification of upcoming software
|
||||
releases and formal reviews of proposed libraries. One to three messages
|
||||
per month. Subscribe or unsubscribe at the <a href=
|
||||
"http://lists.boost.org/mailman/listinfo.cgi/boost-announce">Boost Announce
|
||||
list home page</a>.</p><a name="interest" id="interest"></a>
|
||||
|
||||
<h2>Boost Interest Mailing List</h2>
|
||||
|
||||
<p>This list is a moderated low-traffic announcement-only list of
|
||||
interest to the Boost community. On topic messages will include
|
||||
announcements of books, magazine articles, papers, talks, seminars,
|
||||
products, tools, events, or conferences on advanced uses of C++,
|
||||
generic/generative/meta-programming, and, of course, the Boost
|
||||
libraries. Off topic will be discussion of any kind. Job postings
|
||||
are accepted at the moderators' discretion. Subscribe or
|
||||
unsubscribe at the <a href=
|
||||
"http://lists.boost.org/mailman/listinfo.cgi/boost-interest">Boost-Interest
|
||||
home page</a>.</p>
|
||||
|
||||
<h2><a name="projects" id="projects">Project-Specific lists</a></h2>Several
|
||||
mailing lists have been established for specific Boost projects:
|
||||
|
||||
<dl>
|
||||
<dd>
|
||||
<h3><a name="jamboost" id="jamboost">Boost.Build</a>
|
||||
list</h3>The mailing list for the <a href=
|
||||
"../tools/build">Boost Build System</a> is located <a href=
|
||||
"http://lists.boost.org/mailman/listinfo.cgi/boost-build">here</a>. GMane provides
|
||||
<a href="news://news.gmane.org/gmane.comp.lib.boost.build">NNTP
|
||||
access</a> and <a href=
|
||||
"http://news.gmane.org/thread.php?group=gmane.comp.lib.boost.build">Searchable
|
||||
Archives</a> as well.
|
||||
|
||||
<h3><a name="cplussig" id="cplussig">Python C++-Sig</a> (for
|
||||
Boost.Python)</h3>The <a href=
|
||||
"http://www.python.org/community/sigs/current/c++-sig/">Python C++-sig</a> is not
|
||||
strictly Boost-specific, but nearly all the traffic concerns <a href=
|
||||
"../libs/python">Boost.Python</a>. See also the <a href=
|
||||
"#langbinding">Language Binding</a> list below. GMane provides <a href=
|
||||
"news://news.gmane.org/gmane.comp.python.c%2b%2b">NNTP access</a> and
|
||||
<a href=
|
||||
"http://news.gmane.org/thread.php?group=gmane.comp.python.c%2b%2b">Searchable
|
||||
Archives</a> as well. There are also searchable archives at
|
||||
<a href=
|
||||
"http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/cpp-sig">ASPN</a>.
|
||||
|
||||
<h3><a name="langbinding" id="langbinding">Language Binding</a></h3>The
|
||||
<a href=
|
||||
"http://lists.sourceforge.net/lists/listinfo/boost-langbinding">Language
|
||||
Binding</a> list is for discussion of a generalized framework for
|
||||
binding C++ to other languages and systems based on the technology of
|
||||
<a href="../libs/python">Boost.Python</a> and <a href=
|
||||
"http://luabind.sourceforge.net/">Luabind</a>. The plan is to provide a
|
||||
single front-end for describing bindings with runtime-pluggable back
|
||||
ends for binding to specific languages. It is <b>highly recommended</b>
|
||||
that new subscribers read through the <a href=
|
||||
"http://news.gmane.org/thread.php?group=gmane.comp.lib.boost.langbinding">
|
||||
message history</a> <b>from the beginning</b> before posting; it will
|
||||
save time as much design progress has already been made. GMane provides
|
||||
<a href="news://news.gmane.org/gmane.comp.lib.boost.langbinding">NNTP
|
||||
access</a> and <a href=
|
||||
"http://news.gmane.org/thread.php?group=gmane.comp.lib.boost.langbinding">
|
||||
Searchable Archives</a> as well.
|
||||
|
||||
|
||||
<h3><a name="spirit" id="spirit">Boost.Spirit</a> lists</h3>Spirit has
|
||||
two additional mailing lists. <a href=
|
||||
"https://lists.sourceforge.net/lists/listinfo/spirit-general">Spirit-general</a>
|
||||
for Spirit users and <a href=
|
||||
"https://lists.sourceforge.net/lists/listinfo/spirit-devel">Spirit-devel</a>
|
||||
for Spirit developers (open to anyone who wishes to hang out with
|
||||
Spirit coders). Both have <a href="http://www.gmane.org">GMane</a> NNTP
|
||||
access (<a href=
|
||||
"news://news.gmane.org/gmane.comp.parsers.spirit.general">Spirit-general</a>
|
||||
and <a href=
|
||||
"news://news.gmane.org/gmane.comp.parsers.spirit.devel">Spirit-devel</a>)
|
||||
with searchable archives ( <a href=
|
||||
"http://news.gmane.org/thread.php?group=gmane.comp.parsers.spirit.general">
|
||||
Spirit-general</a> and <a href=
|
||||
"http://news.gmane.org/thread.php?group=gmane.comp.parsers.spirit.devel">
|
||||
Spirit-devel</a>).
|
||||
|
||||
|
||||
<h3><a name="boostdocs" id="boostdocs">Boost.Documentation</a>
|
||||
list</h3>The SourceForge mailing list for the <a href=
|
||||
"../doc/html/boostbook.html">Boost Documentation System</a> is located <a href=
|
||||
"https://lists.sourceforge.net/lists/listinfo/boost-docs">here</a>.
|
||||
GMane provides <a href=
|
||||
"news://news.gmane.org/gmane.comp.lib.boost.documentation">NNTP
|
||||
access</a> and <a href=
|
||||
"http://news.gmane.org/thread.php?group=gmane.comp.lib.boost.documentation">
|
||||
Searchable Archives</a> as well.
|
||||
|
||||
|
||||
<h3><a name="ublas" id="ublas">uBLAS development</a> (ublas-dev)
|
||||
list</h3>A seperate user and developer mailing list for <a href=
|
||||
"../libs/numeric/ublas/doc/index.htm">Boost uBLAS</a> specific topics is
|
||||
located <a href="http://lists.boost.org/">here</a>.
|
||||
|
||||
<h3><a name="thread" id="thread">Thread development</a> (threads-devel)
|
||||
list</h3>A seperate developer mailing list for <a href=
|
||||
"../libs/thread/doc/index.html">Boost Thread</a> specific topics is
|
||||
located
|
||||
<a href="http://lists.boost.org/mailman/listinfo.cgi/threads-devel">here</a>.
|
||||
<p><strong>Important: </strong>This mailing list is for the discussion of
|
||||
the specification and implementation of Boost.Threads only —
|
||||
questions regarding usage should be directed to the
|
||||
<a href="#users">Boost Users</a> list, or the main
|
||||
<a href="#main">Boost developers</a> list.
|
||||
|
||||
|
||||
<p>GMane provides <a href=
|
||||
"news://news.gmane.org/gmane.comp.lib.boost.threads-devel">NNTP
|
||||
access</a> and <a href=
|
||||
"http://news.gmane.org/thread.php?group=gmane.comp.lib.boost.threads-devel">
|
||||
Searchable Archives</a> as well.
|
||||
|
||||
|
||||
<h3><a name="testing" id="testing">Testing</a> list</h3>
|
||||
|
||||
<p>The setup, procedures and tools necessary for running Boost
|
||||
regression tests are discussed on <a href=
|
||||
"http://lists.boost.org/mailman/listinfo.cgi/boost-testing">this
|
||||
list</a>. The list main participants are regression runners - people
|
||||
who run Boost tests on a variety of compilers and platforms, and the
|
||||
maintainers of tools for collecting and processing test results.</p>
|
||||
|
||||
<p><b>Important:</b> questions relevant to a wider audience, including
|
||||
questions about Boost.Test framework or test results for a particular
|
||||
library, should be posted to main development list.</p><a href=
|
||||
"news://news.gmane.org/gmane.comp.lib.boost.documentation">NNTP
|
||||
access</a> and <a href=
|
||||
"http://news.gmane.org/gmane.comp.lib.boost.testing">Searchable
|
||||
Archives</a> are available on <a href="http://www.gmane.org">GMane</a>.
|
||||
|
||||
<h3>Boost Subversion Commit Messages</h3>
|
||||
<p>The <a
|
||||
href="http://lists.boost.org/mailman/listinfo.cgi/boost-commit">boost-commit</a>
|
||||
mailing list receives messages whenever a change is committed to
|
||||
the Boost Subversion repository.</p>
|
||||
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2>Boost <a name="sandbox" id="sandbox">Sandbox</a></h2>
|
||||
|
||||
<p>In addition to the main <a href="getting_started.html#CVS">Boost CVS
|
||||
repository</a>, a separate Sandbox is available for Boost developers
|
||||
wishing to collaborate on projects prior to formal acceptance of a new
|
||||
library. Read-only access is available via Subversion and web browser at
|
||||
<a href=
|
||||
"http://svn.boost.org/svn/boost/sandbox">http://svn.boost.org/svn/boost/sandbox</a>.
|
||||
|
||||
<p>Developer access to the sandbox uses the Subversion repository
|
||||
at <a href=
|
||||
"https://svn.boost.org/svn/boost/sandbox">https://svn.boost.org/svn/boost/sandbox</a>. For more information about the Boost Subversion repository,
|
||||
please
|
||||
see <a href="http://svn.boost.org">http://svn.boost.org</a>.</p>
|
||||
|
||||
<h2>#boost <a name="IRC" id="IRC">IRC</a> channel</h2>
|
||||
|
||||
<p>In addition to the mailing lists presented above, a #boost IRC channel on
|
||||
<a href="http://freenode.net">freenode</a> is frequented by some boost users.
|
||||
As usual with IRC channels, one should not necessarily expect that his questions
|
||||
will be answered. The channel is not moderated.</p>
|
||||
<hr>
|
||||
|
||||
<p>Revised
|
||||
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y"
|
||||
startspan -->04 December, 2005<!--webbot bot="Timestamp" endspan
|
||||
i-checksum="39365" --></p>
|
||||
|
||||
<p>Copyright Beman Dawes and David Abrahams 2001-2005</p>
|
||||
|
||||
<p>Distributed under the Boost Software License, Version 1.0. (See
|
||||
accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy
|
||||
at <a href="http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>)</p>
|
||||
</body>
|
||||
</html>
|
@ -1,81 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
||||
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
||||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||||
<title>Moderators</title>
|
||||
</head>
|
||||
|
||||
<body bgcolor="#FFFFFF" text="#000000">
|
||||
|
||||
<table border="1" bgcolor="#007F7F" cellpadding="2">
|
||||
<tr>
|
||||
<td bgcolor="#FFFFFF"><img src="../boost.png" alt="boost.png (6897 bytes)" width="277" height="86"></td>
|
||||
<td><a href="../index.htm"><font face="Arial" color="#FFFFFF"><big>Home</big></font></a></td>
|
||||
<td><a href="../libs/libraries.htm"><font face="Arial" color="#FFFFFF"><big>Libraries</big></font></a></td>
|
||||
<td><a href="../people/people.htm"><font face="Arial" color="#FFFFFF"><big>People</big></font></a></td>
|
||||
<td><a href="faq.htm"><font face="Arial" color="#FFFFFF"><big>FAQ</big></font></a></td>
|
||||
<td><a href="index.htm"><font face="Arial" color="#FFFFFF"><big>More</big></font></a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<h1>Boost Moderators</h1>
|
||||
<p>The Boost moderators are <a href="../people/dave_abrahams.htm">Dave Abrahams</a>,
|
||||
Carl Daniel, <a href="../people/beman_dawes.html">Beman Dawes</a>,
|
||||
<a href="../people/jeff_garland.html">Jeff Garland</a>,
|
||||
<a href="../people/doug_gregor.html">Doug Gregor</a>, and
|
||||
<a href="../people/john_maddock.htm">John Maddock</a>. You can reach
|
||||
the moderators at <a
|
||||
href="mailto:boost-owner@lists.boost.org">boost-owner@lists.boost.org</a>.
|
||||
<p>
|
||||
<b>Note:</b> The boost moderators do not moderate any mailing lists
|
||||
other than the main Boost developers' list. For example, the
|
||||
boost-users list moderators are at
|
||||
<a
|
||||
href="mailto:boost-users-owner@lists.boost.org">boost-users-owner@lists.boost.org</a>.
|
||||
The moderators of <a href="mailing_lists.htm">every other Boost list</a> can be reached
|
||||
through its home page.
|
||||
</p>
|
||||
|
||||
<h2>Moderator Functions</h2>
|
||||
<ul>
|
||||
<li>Monitor the mailing list to ensure dialog remains within the acceptable
|
||||
boundaries set by the <a href="discussion_policy.htm">discussion policy</a>.
|
||||
When discussion strays, use private email to gently remind, strongly rebuke,
|
||||
or outright ban, as the situation demands.</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>Approve the initial postings of new (and thus still moderated) members,
|
||||
and move members to the "Group Policy" posting status.</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>Administer the internal operations of the Boost web site, the main Boost
|
||||
mailing list, the CVS repository, and other Boost administrative machinery.</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>Act as an executive committee overseeing important administrative and
|
||||
policy decisions. Boost is a zero-budget organization with no income
|
||||
and no expenses, so that eliminates the need for most management. Technical
|
||||
decisions are worked out on the mailing list. The moderators handle the few
|
||||
remaining decisions that need a definite answer.</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>Beyond the purely administrative duties, work to keep the Boost community
|
||||
vibrant and alive. That may be as simple as saying "thank you" to
|
||||
an individual member, or as complex as starting some major new
|
||||
initiative. Do whatever it takes!</li>
|
||||
</ul>
|
||||
<hr>
|
||||
<p>Revised <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->27 February, 2005<!--webbot bot="Timestamp" endspan i-checksum="40414" -->
|
||||
</p>
|
||||
<p>© Beman Dawes 2001-2004</p>
|
||||
|
||||
<p>Distributed under the Boost Software License, Version 1.0. (See
|
||||
accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy
|
||||
at <a href=
|
||||
"http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>)</p>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
@ -5,5 +5,14 @@
|
||||
<body>
|
||||
Automatically loading index page... if nothing happens, please go to
|
||||
<a href="../tools/regression/index.htm">http://www.boost.org/tools/regression/index.htm</a>.
|
||||
<hr>
|
||||
|
||||
<p>© Copyright Douglas Gregor, 2005</p>
|
||||
|
||||
<p>Distributed under the Boost Software License, Version 1.0. See
|
||||
<a href="http://www.boost.org/LICENSE_1_0.txt">www.boost.org/LICENSE_1_0.txt</a></p>
|
||||
|
||||
<p> </p>
|
||||
<p> </p>
|
||||
</body>
|
||||
</html>
|
423
report-nov-2007.html
Normal file
423
report-nov-2007.html
Normal file
@ -0,0 +1,423 @@
|
||||
<?xml version="1.0" encoding="utf-8" ?>
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||||
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
<meta name="generator" content="Docutils 0.3.8: http://docutils.sourceforge.net/" />
|
||||
<title>Review Wizard Status Report for November 2007</title>
|
||||
<link rel="stylesheet" href="http://boost.org/rst.css" type="text/css" />
|
||||
</head>
|
||||
<body>
|
||||
<div class="document" id="review-wizard-status-report-for-november-2007">
|
||||
<h1 class="title">Review Wizard Status Report for November 2007</h1>
|
||||
<div class="section" id="news">
|
||||
<h1><a name="news">News</a></h1>
|
||||
<dl class="docutils">
|
||||
<dt>November 7, 2007 - Exception Library Accepted</dt>
|
||||
<dd>Announcement: <a class="reference" href="http://lists.boost.org/boost-users/2007/11/31912.php">http://lists.boost.org/boost-users/2007/11/31912.php</a></dd>
|
||||
</dl>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="review-queue">
|
||||
<h1><a name="review-queue">Review Queue</a></h1>
|
||||
<ul class="simple">
|
||||
<li>Finite State Machines</li>
|
||||
<li>Floating Point Utilities</li>
|
||||
<li>Switch</li>
|
||||
<li>Property Map (fast-track)</li>
|
||||
<li>Graph (fast-track)</li>
|
||||
<li>Forward (fast-track)</li>
|
||||
<li>Singleton (fast-track)</li>
|
||||
<li>Factory (fast-track)</li>
|
||||
<li>Lexer</li>
|
||||
<li>Thread-Safe Signals</li>
|
||||
<li>Logging</li>
|
||||
<li>Flyweight</li>
|
||||
<li>Unordered Containers</li>
|
||||
</ul>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="finite-state-machines">
|
||||
<h2><a name="finite-state-machines">Finite State Machines</a></h2>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Andrey Semashev</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body">Martin Vuille</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><a class="reference" href="http://tinyurl.com/yjozfn">Boost Sandbox Vault</a></td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body"><p class="first">The Boost.FSM library is an implementation of FSM (stands for
|
||||
Finite State Machine) programming concept. The main goals of the
|
||||
library are:</p>
|
||||
<ul class="last simple">
|
||||
<li>Simplicity. It should be very simple to create state machines using
|
||||
this library.</li>
|
||||
<li>Performance. The state machine infrastructure should not be
|
||||
very time and memory-consuming in order to be applicable in
|
||||
more use cases.</li>
|
||||
<li>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.</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="floating-point-utilities">
|
||||
<h2><a name="floating-point-utilities">Floating Point Utilities</a></h2>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Johan Råde</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body">Need Volunteer</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><a class="reference" href="http://boost-consulting.com/vault/index.php?directory=Math%20-%20Numerics">Boost Sandbox Vault</a></td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body"><p class="first">The Floating Point Utilities library contains the following:</p>
|
||||
<ul class="last simple">
|
||||
<li>Floating point number classification functions: fpclassify, isfinite,
|
||||
isinf, isnan, isnormal (Follows TR1)</li>
|
||||
<li>Sign bit functions: signbit, copysign, changesign (Follows TR1)</li>
|
||||
<li>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).</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="switch">
|
||||
<h2><a name="switch">Switch</a></h2>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Steven Watanabe</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body">Need Volunteer</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><a class="reference" href="http://boost-consulting.com/vault/index.php?action=downloadfile&filename=mcs_units_v0.7.1.zip&directory=Units">Boost Sandbox Vault</a></td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body">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.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="property-map-fast-track">
|
||||
<h2><a name="property-map-fast-track">Property Map (fast-track)</a></h2>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Andrew Sutton</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body">Jeremy Siek</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><a class="reference" href="http://svn.boost.org/svn/boost/sandbox/graph-v2">http://svn.boost.org/svn/boost/sandbox/graph-v2</a></td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body"><p class="first">A number of additions and modifications to the Property Map Library,
|
||||
including:</p>
|
||||
<ul class="last simple">
|
||||
<li>A constant-valued property map, useful for naturally unweighted
|
||||
graphs.</li>
|
||||
<li>A noop-writing property map, useful when you have to provide an
|
||||
argument, but just don't care about the output.</li>
|
||||
<li>See
|
||||
<a class="reference" href="http://svn.boost.org/trac/boost/browser/sandbox/graph-v2/libs/property_map/ChangeLog">ChangeLog</a>
|
||||
for details.</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="graph-fast-track">
|
||||
<h2><a name="graph-fast-track">Graph (fast-track)</a></h2>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Andrew Sutton</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body">Jeremy Siek</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><a class="reference" href="http://svn.boost.org/svn/boost/sandbox/graph-v2">http://svn.boost.org/svn/boost/sandbox/graph-v2</a></td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body"><p class="first">A number of additions and modifications to the Graph Library,
|
||||
including:</p>
|
||||
<ul class="last simple">
|
||||
<li>Two new graph classes (undirected and directed) which are intended
|
||||
to make the library more approachable for new developers</li>
|
||||
<li>A suite of graph measures including degree and closeness
|
||||
centrality, mean geodesic distance, eccentricity, and clustering
|
||||
coefficients.</li>
|
||||
<li>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).</li>
|
||||
<li>An algorithm for visiting all the cliques a graph (Bron&Kerbosch).
|
||||
Works for both directed and undirected.</li>
|
||||
<li>Derived graph measures radius and diameter (from eccentricity) and
|
||||
girth and circumference (from Tiernan), and clique number (from
|
||||
Bron&Kerbosch).</li>
|
||||
<li>An exterior_property class that helps hides some of the weirdness
|
||||
with exterior properties.</li>
|
||||
<li>runtime and compile-time tests for the new algorithms.</li>
|
||||
<li>a substantial amount of documentation</li>
|
||||
<li>Graph cores, implemented by David Gleich (@Stanford University)</li>
|
||||
<li>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.</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="forward-fast-track">
|
||||
<h2><a name="forward-fast-track">Forward (fast-track)</a></h2>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Tobias Schwinger</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body">John Torjo</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><a class="reference" href="http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=X-Files">http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=X-Files</a></td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body">A brute-force solution to the forwarding problem.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="singleton-fast-track">
|
||||
<h2><a name="singleton-fast-track">Singleton (fast-track)</a></h2>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Tobias Schwinger</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body">John Torjo</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><a class="reference" href="http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=X-Files">http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=X-Files</a></td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body">Three thread-safe Singleton templates with an
|
||||
easy-to-use interface.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="factory-fast-track">
|
||||
<h2><a name="factory-fast-track">Factory (fast-track)</a></h2>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Tobias Schwinger</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body">John Torjo</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><a class="reference" href="http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=X-Files">http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=X-Files</a></td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body">Generic factories.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="lexer">
|
||||
<h2><a name="lexer">Lexer</a></h2>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Ben Hanson</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body">Need Volunteer</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><a class="reference" href="http://boost-consulting.com/vault/index.php?action=downloadfile&filename=boost.lexer.zip&directory=Strings%20">http://boost-consulting.com/vault/index.php?action=downloadfile&filename=boost.lexer.zip&directory=Strings%20</a>-%20Text%20Processing&</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body">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.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="thread-safe-signals">
|
||||
<h2><a name="thread-safe-signals">Thread-Safe Signals</a></h2>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Frank Hess</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body">Need Volunteer</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><a class="reference" href="http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directory=thread_safe_signals">http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directory=thread_safe_signals</a></td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body">A thread-safe implementation of Boost.signals that
|
||||
has some interface changes to accommodate thread safety, mostly with
|
||||
respect to automatic connection management.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="logging">
|
||||
<h2><a name="logging">Logging</a></h2>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body">John Torjo</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body">Need Volunteer</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><a class="reference" href="http://torjo.com/log2/">http://torjo.com/log2/</a></td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body">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!</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="flyweight">
|
||||
<h2><a name="flyweight">Flyweight</a></h2>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Joaquín M López Muñoz</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body">Need Volunteer</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><a class="reference" href="http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=flyweight.zip&directory=Patterns">http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=flyweight.zip&directory=Patterns</a></td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body">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.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="unordered-containers">
|
||||
<h2><a name="unordered-containers">Unordered Containers</a></h2>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Daniel James</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body">Need Volunteer</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><a class="reference" href="http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=unordered.zip&directory=Containers">http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=unordered.zip&directory=Containers</a></td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body">An implementation of the unordered containers specified
|
||||
in TR1, with most of the changes from the recent draft standards.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="libraries-under-development">
|
||||
<h1><a name="libraries-under-development">Libraries under development</a></h1>
|
||||
<div class="section" id="dataflow">
|
||||
<h2><a name="dataflow">Dataflow</a></h2>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Stjepan Rajko</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body">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.</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Status:</th><td class="field-body">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.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="constrained-value">
|
||||
<h2><a name="constrained-value">Constrained Value</a></h2>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Robert Kawulak</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><p class="first"><a class="reference" href="http://rk.go.pl/f/constrained_value.zip">http://rk.go.pl/f/constrained_value.zip</a></p>
|
||||
<p class="last"><a class="reference" href="http://rk.go.pl/r/constrained_value">http://rk.go.pl/r/constrained_value</a> (Documentation)</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body">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.</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Status:</th><td class="field-body">I'm planning to finish it in 1-2 months.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Please let us know of any libraries you are currently
|
||||
developing that you intend to submit for review.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
329
report-sep-2007.html
Normal file
329
report-sep-2007.html
Normal file
@ -0,0 +1,329 @@
|
||||
<?xml version="1.0" encoding="utf-8" ?>
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||||
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
<meta name="generator" content="Docutils 0.5: http://docutils.sourceforge.net/" />
|
||||
<title>Review Wizard Status Report for September 2007</title>
|
||||
<link rel="stylesheet" href="http://boost.org/rst.css" type="text/css" />
|
||||
</head>
|
||||
<body>
|
||||
<div class="document" id="review-wizard-status-report-for-september-2007">
|
||||
<h1 class="title">Review Wizard Status Report for September 2007</h1>
|
||||
|
||||
<div class="section" id="news">
|
||||
<h1>News</h1>
|
||||
<dl class="docutils">
|
||||
<dt>August 17, 2007 -- Time Series Accepted.</dt>
|
||||
<dd>Announcement: <a class="reference external" href="http://lists.boost.org/boost-announce/2007/08/0142.php">http://lists.boost.org/boost-announce/2007/08/0142.php</a></dd>
|
||||
<dt>July 24, 2007 -- Boost Version 1.34.1 Released.</dt>
|
||||
<dd>This is a bug fix release addressing many problems with the 1.34.0 release.
|
||||
Announcement: <a class="reference external" href="http://svn.boost.org/trac/boost/query?status=closed&milestone=Boost+1.34.1">http://svn.boost.org/trac/boost/query?status=closed&milestone=Boost+1.34.1</a></dd>
|
||||
</dl>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<div class="section" id="review-queue">
|
||||
<h1>Review Queue</h1>
|
||||
<blockquote>
|
||||
<ul class="simple">
|
||||
<li>Exception</li>
|
||||
<li>Finite State Machines</li>
|
||||
<li>Floating Point Utilities</li>
|
||||
<li>Switch</li>
|
||||
<li>Property Map (fast-track)</li>
|
||||
<li>Graph (fast-track)</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="exception">
|
||||
<h2>Exception</h2>
|
||||
<blockquote>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body"><p class="first">Emil Dotchevski</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body"><p class="first">Need Volunteer</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><p class="first"><a class="reference external" href="http://www.revergestudios.com/boost-exception/boost-exception.zip">http://www.revergestudios.com/boost-exception/boost-exception.zip</a></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body"><p class="first">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.</p>
|
||||
<p class="last">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.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
</div>
|
||||
<div class="section" id="finite-state-machines">
|
||||
<h2>Finite State Machines</h2>
|
||||
<blockquote>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body"><p class="first">Andrey Semashev</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body"><p class="first">Martin Vuille</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><p class="first"><a class="reference external" href="http://tinyurl.com/yjozfn">Boost Sandbox Vault</a></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body"><p class="first">The Boost.FSM library is an implementation of FSM (stands for
|
||||
Finite State Machine) programming concept. The main goals of the
|
||||
library are:</p>
|
||||
<ul class="last simple">
|
||||
<li>Simplicity. It should be very simple to create state machines using
|
||||
this library.</li>
|
||||
<li>Performance. The state machine infrastructure should not be
|
||||
very time and memory-consuming in order to be applicable in
|
||||
more use cases.</li>
|
||||
<li>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.</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
</div>
|
||||
<div class="section" id="floating-point-utilities">
|
||||
<h2>Floating Point Utilities</h2>
|
||||
<blockquote>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body"><p class="first">Johan RÂde</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body"><p class="first">Need Volunteer</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><p class="first"><a class="reference external" href="http://boost-consulting.com/vault/index.php?directory=Math%20-%20Numerics">Boost Sandbox Vault</a></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body"><p class="first">The Floating Point Utilities library contains the following:</p>
|
||||
<ul class="last simple">
|
||||
<li>Floating point number classification functions: fpclassify, isfinite,
|
||||
isinf, isnan, isnormal (Follows TR1)</li>
|
||||
<li>Sign bit functions: signbit, copysign, changesign (Follows TR1)</li>
|
||||
<li>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.)</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
</div>
|
||||
<div class="section" id="switch">
|
||||
<h2>Switch</h2>
|
||||
<blockquote>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Steven Watanabe</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body">Need Volunteer</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><a class="reference external" href="http://boost-consulting.com/vault/index.php?action=downloadfile&filename=mcs_units_v0.7.1.zip&directory=Units">Boost Sandbox Vault</a></td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body">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.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
</div>
|
||||
<div class="section" id="property-map-fast-track">
|
||||
<h2>Property Map (fast-track)</h2>
|
||||
<blockquote>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body"><p class="first">Andrew Sutton</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body"><p class="first">Jeremy Siek</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><p class="first"><a class="reference external" href="http://svn.boost.org/svn/boost/sandbox/graph-v2">http://svn.boost.org/svn/boost/sandbox/graph-v2</a></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body"><p class="first">A number of additions and modifications to the Property Map Library,
|
||||
including:</p>
|
||||
<blockquote class="last">
|
||||
<ul class="simple">
|
||||
<li>A constant-valued property map, useful for naturally unweighted
|
||||
graphs.</li>
|
||||
<li>A noop-writing property map, useful when you have to provide an
|
||||
argument, but just don't care about the output.</li>
|
||||
<li>See
|
||||
<a class="reference external" href="http://svn.boost.org/trac/boost/browser/sandbox/graph-v2/libs/property_map/ChangeLog">ChangeLog</a>
|
||||
for details.</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
</div>
|
||||
<div class="section" id="graph-fast-track">
|
||||
<h2>Graph (fast-track)</h2>
|
||||
<blockquote>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body"><p class="first">Andrew Sutton</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Review Manager:</th><td class="field-body"><p class="first">Jeremy Siek</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><p class="first"><a class="reference external" href="http://svn.boost.org/svn/boost/sandbox/graph-v2">http://svn.boost.org/svn/boost/sandbox/graph-v2</a></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body"><p class="first">A number of additions and modifications to the Graph Library,
|
||||
including:</p>
|
||||
<ul class="last simple">
|
||||
<li>Two new graph classes (undirected and directed) which are intended
|
||||
to make the library more approachable for new developers</li>
|
||||
<li>A suite of graph measures including degree and closeness
|
||||
centrality, mean geodesic distance, eccentricity, and clustering
|
||||
coefficients.</li>
|
||||
<li>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).</li>
|
||||
<li>An algorithm for visiting all the cliques a graph (Bron&Kerbosch).
|
||||
Works for both directed and undirected.</li>
|
||||
<li>Derived graph measures radius and diameter (from eccentricity) and
|
||||
girth and circumference (from Tiernan), and clique number (from
|
||||
Bron&Kerbosch).</li>
|
||||
<li>An exterior_property class that helps hides some of the weirdness
|
||||
with exterior properties.</li>
|
||||
<li>runtime and compile-time tests for the new algorithms.</li>
|
||||
<li>a substantial amount of documentation</li>
|
||||
<li>Graph cores, implemented by David Gleich (@Stanford University)</li>
|
||||
<li>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.</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="libraries-under-development">
|
||||
<h1>Libraries under development</h1>
|
||||
<div class="section" id="dataflow">
|
||||
<h2>Dataflow</h2>
|
||||
<blockquote>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Stjepan Rajko</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body">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.</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Status:</th><td class="field-body">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.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
</div>
|
||||
<div class="section" id="constrained-value">
|
||||
<h2>Constrained Value</h2>
|
||||
<blockquote>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">Author:</th><td class="field-body"><p class="first">Robert Kawulak</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Download:</th><td class="field-body"><p class="first"><a class="reference external" href="http://rk.go.pl/f/constrained_value.zip">http://rk.go.pl/f/constrained_value.zip</a></p>
|
||||
<p><a class="reference external" href="http://rk.go.pl/r/constrained_value">http://rk.go.pl/r/constrained_value</a> (Documentation)</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Description:</th><td class="field-body"><p class="first">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.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">Status:</th><td class="field-body"><p class="first last">I'm planning to finish it in 1-2 months.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</blockquote>
|
||||
<p>Please let us know of any libraries you are currently
|
||||
developing that you intend to submit for review.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
@ -1,56 +0,0 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<meta http-equiv="Content-Language" content="en-us">
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
||||
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
||||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||||
<title>Requesting New Features</title>
|
||||
</head>
|
||||
|
||||
<body bgcolor="#FFFFFF" text="#000000">
|
||||
|
||||
<table border="1" bgcolor="#007F7F" cellpadding="2">
|
||||
<tr>
|
||||
<td bgcolor="#FFFFFF">
|
||||
<img src="../boost.png" alt="boost.png (6897 bytes)" width="277" height="86"></td>
|
||||
<td><a href="../index.htm"><font face="Arial" color="#FFFFFF"><big>Home</big></font></a></td>
|
||||
<td><a href="../libs/libraries.htm"><font face="Arial" color="#FFFFFF"><big>
|
||||
Libraries</big></font></a></td>
|
||||
<td><a href="../people/people.htm"><font face="Arial" color="#FFFFFF"><big>
|
||||
People</big></font></a></td>
|
||||
<td><a href="faq.htm"><font face="Arial" color="#FFFFFF"><big>FAQ</big></font></a></td>
|
||||
<td><a href="index.htm"><font face="Arial" color="#FFFFFF"><big>More</big></font></a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<h1>Requesting new features for Boost libraries</h1>
|
||||
<p>If you have an idea for a feature or improvement to an existing Boost library
|
||||
- go ahead and post it to either
|
||||
<a href="http://www.boost.org/more/mailing_lists.htm#users">boost-users list</a>
|
||||
or <a href="http://www.boost.org/more/mailing_lists.htm#main">boost mailing list</a>
|
||||
(if you are posting for the first time, please read our
|
||||
<a href="http://www.boost.org/more/discussion_policy.htm">discussion policy</a>
|
||||
before you actually post). </p>
|
||||
<p>You can also use our <a href="http://sourceforge.net/tracker/?group_id=7586">
|
||||
feature request tracking facility</a> at SourceForge, but experience has shown
|
||||
that posting to either of the mailing lists is usually a more effective way to
|
||||
get attention of boost developers. </p>
|
||||
<p>If your proposal has its merits, it's very likely that it will generate a
|
||||
constructive discussion that might actually result in (sometimes substantial)
|
||||
improvement of the library - and your name being put on the library's
|
||||
<a href="http://www.boost.org/more/lib_guide.htm#Acknowledgements">
|
||||
Acknowledgements</a> section! </p>
|
||||
<hr>
|
||||
<p>Revised <!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan -->26 November, 2003<!--webbot bot="Timestamp" i-checksum="39365" endspan -->
|
||||
</p>
|
||||
|
||||
<p>© Copyright <a href="../people/aleksey_gurtovoy.htm">Aleksey Gurtovoy</a>
|
||||
2002</p>
|
||||
<p> Distributed under the Boost Software License, Version 1.0.
|
||||
(See accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or
|
||||
copy at <a href="http://www.boost.org/LICENSE_1_0.txt">www.boost.org/LICENSE_1_0.txt</a>)
|
||||
</p>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
@ -1,385 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<title>Guidelines for Authors of Boost Libraries Containing Separate Source</title>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
||||
<LINK href="../boost.css" type="text/css" rel="stylesheet"></head>
|
||||
<body>
|
||||
<TABLE summary="Page header" id="Table1" cellSpacing="1" cellPadding="1" width="100%" border="0">
|
||||
<TR>
|
||||
<td vAlign="top" width="300">
|
||||
<h3><A href="../index.htm"><IMG height="86" alt="C++ Boost" src="../boost.png" width="277" border="0"></A></h3>
|
||||
</td>
|
||||
<TD width="353">
|
||||
<H1 align="center">Guidelines for Authors of Boost Libraries Containing Separate
|
||||
Source</H1>
|
||||
</TD>
|
||||
</TR>
|
||||
</TABLE>
|
||||
<BR>
|
||||
<HR>
|
||||
<P>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.</P>
|
||||
<H2>Contents</H2>
|
||||
<dl class="index">
|
||||
<dt><A href="#source_changes">Changes Affecting Source Code</A>
|
||||
<dd>
|
||||
<dl class="index">
|
||||
<dt><A href="#abi">Preventing Compiler ABI Clashes</A> <DT><A href="#static_or_dynamic">Static
|
||||
or Dymanic Libraries</A> <dt><A href="#dlls">Supporting Windows Dll's</A> <dt>
|
||||
<a href="#auto-link">Automatic Library Selection and Linking with auto_link.hpp</a>
|
||||
</dt>
|
||||
</dl>
|
||||
<dt><A href="#build_changes">Changes Affecting the Build System</A>
|
||||
<dd>
|
||||
<dl class="index">
|
||||
<dt><A href="#jamfile">Creating the Library Jamfile</A> <dt><A href="#testing">Testing
|
||||
Auto-linking</A> </dt>
|
||||
</dl>
|
||||
<dt><A href="#copyright">Copyright</A></dt>
|
||||
</dl>
|
||||
<h2><A name="source_changes"></A>Changes Affecting Source Code</h2>
|
||||
<H3><A name="abi"></A>Preventing Compiler ABI Clashes</H3>
|
||||
<P>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:</P>
|
||||
<PRE>-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).
|
||||
</PRE>
|
||||
<P>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!
|
||||
</P>
|
||||
<P>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.</P>
|
||||
<P>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:</P>
|
||||
<PRE>#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
|
||||
</PRE>
|
||||
<P>You can include this code in your library source files as well if you want,
|
||||
although you probably shouldn't need to: </P>
|
||||
<UL>
|
||||
<LI>
|
||||
If you <EM>don't</EM>
|
||||
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.
|
||||
<LI>
|
||||
If you <EM>do </EM>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.</LI></UL>
|
||||
<H4>Rationale:</H4>
|
||||
<P>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.</P>
|
||||
<H5>Counter Argument #1:</H5>
|
||||
<P>Trust the user, if they want 13-byte alignment (!) let them have it.</P>
|
||||
<H5>Counter Argument #2:</H5>
|
||||
<P>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.</P>
|
||||
<H3><A name="static_or_dynamic"></A>Static or Dynamic Libraries</H3>
|
||||
<P>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:</P>
|
||||
<UL>
|
||||
<LI>
|
||||
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.
|
||||
<LI>
|
||||
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.
|
||||
<LI>
|
||||
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).</LI></UL>
|
||||
<P>The recomendation is to pick static linking by default.</P>
|
||||
<H4>Rationale:</H4>
|
||||
<P>There is no one policy that fits all here.
|
||||
</P>
|
||||
<P>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.</P>
|
||||
<P>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.</P>
|
||||
<H3>Supporting Windows Dll's</H3>
|
||||
<p>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).</p>
|
||||
<p>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:</p>
|
||||
<pre>#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
|
||||
</pre>
|
||||
And then in the source code for this library one would use:
|
||||
<pre>
|
||||
//
|
||||
// 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();
|
||||
}
|
||||
</pre>
|
||||
<H4>Importing/exporting dependencies</H4>
|
||||
<P>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:</P>
|
||||
<PRE>#ifdef BOOST_MSVC
|
||||
# pragma warning(push)
|
||||
# pragma warning(disable : 4251 4231 4660)
|
||||
#endif
|
||||
|
||||
// code here
|
||||
|
||||
#ifdef BOOST_MSVC
|
||||
#pragma warning(pop)
|
||||
#endif
|
||||
</PRE>
|
||||
<p>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.
|
||||
</p>
|
||||
<p>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.</p>
|
||||
<h4>Rationale:</h4>
|
||||
<p><EM>Why bother - doesn't the import/export mechanism take up more code that the
|
||||
classes themselves?</EM></p>
|
||||
<P>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.</P>
|
||||
<p><EM>Why static linking by default? </EM>
|
||||
</p>
|
||||
<P>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).</P>
|
||||
<h3><A name="auto-link"></A>Automatic Library Selection and Linking with <a href="../boost/config/auto_link.hpp">
|
||||
auto_link.hpp</a></h3>
|
||||
<p>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:</p>
|
||||
<pre>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
|
||||
</pre>
|
||||
<p>The difficulty now is selecting which of these the user should link his or her
|
||||
code to.</p>
|
||||
<p>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.
|
||||
</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<pre>//
|
||||
// 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
|
||||
</pre>
|
||||
<p>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:</p>
|
||||
<P>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.</P>
|
||||
<H2><A name="build_changes"></A>Changes Affecting the Build System</H2>
|
||||
<H3><a name="build"></a><A name="jamfile"></A>Creating the library Jamfile</H3>
|
||||
<P>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:</P>
|
||||
<PRE>
|
||||
lib boost_regex : ../src/whatever.cpp :
|
||||
<link>shared:<define>BOOST_WHATEVER_DYN_LINK=1 ;
|
||||
</PRE>
|
||||
<H3><A name="testing"></A>Testing Auto-linking</H3>
|
||||
<P>Testing the auto-link feature is somewhat convoluted, and requires access
|
||||
to a compiler that supports the feature: refer to <A href="../libs/config/test/link/test/Jamfile.v2">
|
||||
libs/config/test/link/test/Jamfile.v2</A> for an example.</P>
|
||||
<HR>
|
||||
<p><A name="copyright"></A>Revised
|
||||
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
|
||||
26 November, 2003<!--webbot bot="Timestamp" endspan i-checksum="39365" --></p>
|
||||
<p><i>© Copyright John Maddock 1998-
|
||||
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%Y" startspan --> 2003<!--webbot bot="Timestamp" endspan i-checksum="746" --></i></p>
|
||||
<P><I>Distributed under the Boost Software License, Version 1.0. (See accompanying
|
||||
file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy at <a href="http://www.boost.org/LICENSE_1_0.txt">
|
||||
http://www.boost.org/LICENSE_1_0.txt</a>)</I></P>
|
||||
<P><EM>The use of code snippets from this article does not require the reproduction
|
||||
of this copyright notice and license declaration; if you wish to provide
|
||||
attribution then please provide a link to this article.</EM></P>
|
||||
</body>
|
||||
</html>
|
@ -1,133 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
||||
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
||||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||||
<title>Boost Library Submission Process</title>
|
||||
</head>
|
||||
|
||||
<body bgcolor="#FFFFFF" text="#000000">
|
||||
|
||||
<table border="1" bgcolor="#007F7F" cellpadding="2">
|
||||
<tr>
|
||||
<td bgcolor="#FFFFFF"><img src="../boost.png" alt="boost.png (6897 bytes)" width="277" height="86"></td>
|
||||
<td><a href="../index.htm"><font face="Arial" color="#FFFFFF"><big>Home</big></font></a></td>
|
||||
<td><a href="../libs/libraries.htm"><font face="Arial" color="#FFFFFF"><big>Libraries</big></font></a></td>
|
||||
<td><a href="../people/people.htm"><font face="Arial" color="#FFFFFF"><big>People</big></font></a></td>
|
||||
<td><a href="faq.htm"><font face="Arial" color="#FFFFFF"><big>FAQ</big></font></a></td>
|
||||
<td><a href="index.htm"><font face="Arial" color="#FFFFFF"><big>More</big></font></a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<h1>Boost Library Submission Process</h1>
|
||||
<p>This page describes the process a library developer goes through to get a
|
||||
library accepted by Boost.</p>
|
||||
<p>See the <a href="lib_guide.htm">Boost Library Requirements and Guidelines</a>
|
||||
page for issues of content.</p>
|
||||
<h3><b>Steps for getting a library accepted by Boost:</b></h3>
|
||||
<ul>
|
||||
<li><a href="#Learn">Learn about Boost</a>.</li>
|
||||
<li><a href="#interest">Determine interest</a>.</li>
|
||||
<li><a href="#Preliminary">Preliminary submission</a>.</li>
|
||||
<li><a href="#Refinement">Refinement</a>.</li>
|
||||
<li><a href="#Submission">Submission for review</a>.</li>
|
||||
<li><a href="#Review">Formal Review</a>.</li>
|
||||
<li><a href="#SitePosting">Web site posting</a>.</li>
|
||||
<li><a href="#People">People page.</a></li>
|
||||
<li><a href="#Lifecycle">Lifecycle</a>.</li>
|
||||
</ul>
|
||||
<h2><a name="Learn">Learn</a> about Boost</h2>
|
||||
<p>Subscribe to the <a href="mailing_lists.htm#main">main developers mailing list</a> for a
|
||||
while, or look through the <a href="mailing_lists.htm#archive">archives</a>.
|
||||
Click around the <a href="../index.htm">web site</a>. Understand the <a href="lib_guide.htm">Requirements</a>.
|
||||
Read the rest of this page to learn about the process. Otherwise, you will
|
||||
just end up wasting everyone's time.</p>
|
||||
<p>There is a culture associated with Boost, aimed at encouraging high quality
|
||||
libraries by a process of discussion and refinement.</p>
|
||||
<p>If what you really want is a site that will just post your library without
|
||||
even looking at it, you should go elsewhere.</p>
|
||||
<h2>Determine <a name="interest">interest</a></h2>
|
||||
<p>Potential library submitters should use the Boost developers <a href="mailing_lists.htm">mailing
|
||||
list</a> as a forum to gauge interest a possible submission.</p>
|
||||
<p>A message might be as simple as "Is there any interest in a library
|
||||
which solves Traveling Salesperson problems in linear time?"</p>
|
||||
<p>A bit of further description or snippet of code may be helpful. Messages
|
||||
should be plain text; not rich text, HTML, etc.</p>
|
||||
<p>Please don't post lengthy descriptions, documentation, or code to the mailing
|
||||
list, and no attachments, even small ones. Please post lengthy material in
|
||||
the <a href="http://boost-consulting.com/vault/">Boost Vault</a>. </p>
|
||||
<h2><a name="Preliminary">Preliminary</a> submission</h2>
|
||||
<p>If response to an initial query indicates interest, then post the preliminary
|
||||
submission files in the <a href="http://boost-consulting.com/vault/">Boost Vault</a> on
|
||||
the sourceforge web site if you haven't already done so.</p>
|
||||
<h2><a name="Refinement">Refinement</a></h2>
|
||||
<p>Discuss, refine, resubmit. Repeat until satisfied.</p>
|
||||
<p>The exact details of this process varies a lot. Sometimes it is public,
|
||||
on the mailing list, sometimes a lot of discussion happens in private
|
||||
emails. For some libraries the process is over quickly, for others it goes
|
||||
on for months. It's often challenging, and sometimes leads off in
|
||||
completely unexpected directions. </p>
|
||||
<p>The <a href="mailing_lists.htm#archive">archive</a> of past
|
||||
messages is one way to see how this process worked for other Boost
|
||||
libraries.</p>
|
||||
<h2><a name="Submission">Submission</a> for review </h2>
|
||||
<p>All of the files which make up the library should be combined and compressed
|
||||
into a single submission file using the .zip format. Free encoders
|
||||
and decoders for this format running on many different platforms are available
|
||||
at the <a href="http://www.info-zip.org/pub/infozip/">Info-ZIP</a> web site, which
|
||||
includes a FAQ and much other useful information about the .zip format. Many
|
||||
commercial compressor-archiver utilities also support this format.</p>
|
||||
<p>The submission file should contain material as if on the
|
||||
boost.org web site. The closer the submission file mirrors the final
|
||||
<a href="lib_guide.htm#Directory_structure">directory
|
||||
structure</a> and format of the web site, the better.
|
||||
<p>Like a preliminary submission, post the final submission .zip file in the <a href="http://boost-consulting.com/vault/">Boost Vault</a>.
|
||||
<h2>Formal <a name="Review">Review</a></h2>
|
||||
<p>Before asking for formal review, your submission should be posted in the
|
||||
Boost files/vault. Please verify that your submission compiles
|
||||
and runs under at least two compilers. This flushes out obvious
|
||||
portability problems. If you don't have access to a second compiler, ask
|
||||
for help on the Boost mailing list.</p>
|
||||
<p>Once a library author feels a submission (which presumably is now in the
|
||||
files/vault) has matured enough for formal review, the author sends a message
|
||||
requesting a formal review to the mailing list. Please use a subject in
|
||||
the form "Review Request: library" where <i>library</i> is replaced by
|
||||
the library name.</p>
|
||||
<p>See <a href="formal_review_process.htm">Formal Review Process</a> for
|
||||
details.</p>
|
||||
<p>Formal Review schedules are posted on
|
||||
the <a href="formal_review_schedule.html">web site</a>. </p>
|
||||
|
||||
<h2>Boost web <a name="SitePosting">site posting</a></h2>
|
||||
<p>Once an accepted library is ready for inclusion on the Boost web site, the
|
||||
submitter is typically given Boost CVS write access, and expected to check-in
|
||||
and maintain the library in the CVS. Contact the moderators if you need write
|
||||
access or CVS use isn't possible for you.</p>
|
||||
<h2><a name="People">People</a> page</h2>
|
||||
<p>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.</p>
|
||||
<h2><a name="Lifecycle">Lifecycle</a></h2>
|
||||
<p>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 and help someone else take over as the library
|
||||
maintainer.</p>
|
||||
<hr>
|
||||
<p>Revised <!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan -->26 November, 2003<!--webbot bot="Timestamp" endspan i-checksum="39365" --></p>
|
||||
|
||||
<p>© Copyright Beman Dawes 2000</p>
|
||||
<p>Distributed under the Boost Software License, Version 1.0. (See
|
||||
accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy
|
||||
at <a href="http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>)</p>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
100
test_policy.htm
100
test_policy.htm
@ -1,100 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
||||
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
||||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||||
<title>Boost Test Policies and Protocols</title>
|
||||
</head>
|
||||
|
||||
<body bgcolor="#FFFFFF" text="#000000">
|
||||
|
||||
<table border="1" bgcolor="#007F7F" cellpadding="2">
|
||||
<tr>
|
||||
<td bgcolor="#FFFFFF"><img src="../boost.png" alt="boost.png (6897 bytes)" width="277" height="86"></td>
|
||||
<td><a href="../index.htm"><font face="Arial" color="#FFFFFF"><big>Home</big></font></a></td>
|
||||
<td><a href="../libs/libraries.htm"><font face="Arial" color="#FFFFFF"><big>Libraries</big></font></a></td>
|
||||
<td><a href="../people/people.htm"><font face="Arial" color="#FFFFFF"><big>People</big></font></a></td>
|
||||
<td><a href="faq.htm"><font face="Arial" color="#FFFFFF"><big>FAQ</big></font></a></td>
|
||||
<td><a href="index.htm"><font face="Arial" color="#FFFFFF"><big>More</big></font></a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<h1>Boost Test Policies and Protocols</h1>
|
||||
<p>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. </p>
|
||||
<p>"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."</p>
|
||||
<h2>Regression test</h2>
|
||||
<p>Boost uses an automatic <a href="regression.html"> regression test suite</a> which generates HTML
|
||||
<a href="../status/compiler_status.html">compiler
|
||||
status tables</a>.</p>
|
||||
<h2>Test Policy</h2>
|
||||
<h3>Required</h3>
|
||||
<ul>
|
||||
<li>Every Boost library should supply one or more suitable test programs to be
|
||||
exercised by the Boost <a href="regression.html"> regression test suite</a>. 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.</li>
|
||||
<li>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.</li>
|
||||
<li>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.</li>
|
||||
<li>If for any reason the usual test policies do not apply to a particular
|
||||
library, an alternate test strategy must be implemented.</li>
|
||||
<li>A <a href="regression.html#Adding_new_test">Jamfile</a> to drive the
|
||||
regression tests for the library. </li>
|
||||
</ul>
|
||||
<h3>Optional (but highly recommended)</h3>
|
||||
<p>The <a href="../libs/test/index.html">Boost Test Library</a> provides many
|
||||
useful components which ease the construction of test programs.</p>
|
||||
<ul>
|
||||
<li>Use the library's
|
||||
<a href="../libs/test/doc/components/test_tools/index.html">Test Tools</a> for the construction of simple test
|
||||
programs that do not need much structure.</li>
|
||||
<li>Use the library's
|
||||
<a href="../libs/test/doc/components/utf/index.html">Unit Test
|
||||
Framework</a> for the construction of more complex test programs that need to
|
||||
be structured into individual tests
|
||||
and test suites.</li>
|
||||
</ul>
|
||||
<h2>Suggested Protocol for Fixing Bugs or Adding Features.</h2>
|
||||
<ul>
|
||||
<li>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.</li>
|
||||
<li>Second, for bugs, run the regression test and verify that the bug is now
|
||||
detected.</li>
|
||||
<li>Third, then, and only then, fix the bug or add the feature.</li>
|
||||
<li>Finally, rerun the full regression tests - sometimes the change breaks
|
||||
something else.</li>
|
||||
</ul>
|
||||
<h2>History</h2>
|
||||
<p><a href="regression.html#History">See Regression Test History</a>.</p>
|
||||
<h2>Acknowledgements</h2>
|
||||
<p>Written by Beman Dawes. Jens Maurer, Paul Moore, Gary Powell and Jeremy Siek contributed helpful suggestions.</p>
|
||||
<hr>
|
||||
<p>Revised <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->08 January, 2004<!--webbot bot="Timestamp" endspan i-checksum="38708" -->
|
||||
</p>
|
||||
<p>© Copyright Beman Dawes 2001</p>
|
||||
<p>Distributed under the Boost Software License, Version 1.0. (See
|
||||
accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy
|
||||
at <a href="http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>)</p>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
@ -1,111 +0,0 @@
|
||||
<!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>Updating The Boost Website</title>
|
||||
</head>
|
||||
|
||||
<body bgcolor="#FFFFFF" text="#000000">
|
||||
<table border="1" bgcolor="#007F7F" cellpadding="2" summary="Quick Links">
|
||||
<tr>
|
||||
<td bgcolor="#FFFFFF"><img src="../boost.png" alt=
|
||||
"boost.png (6897 bytes)" width="277" height="86" /></td>
|
||||
|
||||
<td><a href="../index.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>Home</big></font></a></td>
|
||||
|
||||
<td><a href="../libs/libraries.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>Libraries</big></font></a></td>
|
||||
|
||||
<td><a href="../people/people.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>People</big></font></a></td>
|
||||
|
||||
<td><a href="faq.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>FAQ</big></font></a></td>
|
||||
|
||||
<td><a href="index.htm"><font face="Arial" color=
|
||||
"#FFFFFF"><big>More</big></font></a></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>Making Updates to the Boost Website Content</h1>
|
||||
|
||||
<p>Any boost developer can update the Boost website content between
|
||||
releases.</p>
|
||||
|
||||
<ul>
|
||||
<li>We <em>strongly</em> recommend the use of <a href=
|
||||
"http://tidy.sourceforge.net/">HTML Tidy</a> when editing HTML and XHTML
|
||||
files intented for the website. Using <code>tidy</code> helps in
|
||||
preventing errors in the HTML, in keeping a clear revision history, and
|
||||
in conforming to Web standards to help make the website readable by the
|
||||
majority of people. The Boost web pages currently have a variety of
|
||||
different types of HTML and XHTML content. Each needs to be dealt with
|
||||
differently by <code>tidy</code>. Most pages are regular HTML 3.x/4.x,
|
||||
for these use a <code>tidy</code> invocation of:
|
||||
<pre>
|
||||
tidy --tidy-mark no -i -wrap 78 -m <i>some_page.html</i>
|
||||
</pre>Other pages are using the more recent XHTML 1.0 and XHTML 1.0 Strict
|
||||
standards. Most notably this include the <a href="../index.htm">home
|
||||
page</a>. Some additional options are needed to make <code>tidy</code>
|
||||
enforce the XHTML standard:
|
||||
<pre>
|
||||
tidy --tidy-mark no -i -wrap 78 -m -asxhtml <i>some_page.html</i>
|
||||
</pre>That command is also useful if one is converting from HTML to XHTML. To
|
||||
have <code>tidy</code> check for the XHTML 1.0 Strict format use:
|
||||
<pre>
|
||||
tidy --tidy-mark no -i -wrap 78 -m -asxhtml --doctype strict <i>some_page.html</i>
|
||||
</pre>If you have a choice as to what format to use, prefer the XHTML 1.0
|
||||
Strict format as that opens the content to the widest audience.
|
||||
</li>
|
||||
|
||||
<li>If the change you are making is intended to be part of a release, you
|
||||
should first make the change in our CVS repository, so it doesn't get
|
||||
lost or overwritten by the next person that updates the page between
|
||||
releases. Of course if you don't check in (say because the change is not
|
||||
supposed to be in the next release), and someone else changes the page
|
||||
after you, the change may be lost. This procedure does not account for
|
||||
that case; you'll have to use your head and figure out what to do.</li>
|
||||
|
||||
<li>You will upload the file(s) by <code>scp</code>'ing to the
|
||||
appropriate subdirectory of
|
||||
<code>shell.sf.net:/home/groups/b/bo/boost/htdocs/</code>. For example,
|
||||
to update the page you are reading, I would issue
|
||||
<pre>
|
||||
scp updating_the_website.html david_abrahams@shell.sf.net:/home/groups/b/bo/boost/htdocs/more/
|
||||
</pre>
|
||||
</li>
|
||||
|
||||
<li>It is <b>crucial</b> to ensure that you set group write permission on
|
||||
every file you upload. If you don't do that, nobody else will be able to
|
||||
change it, which is particularly deadly at release time. If you are on
|
||||
Unix or Cygwin, you may be able to do that with a <tt>chmod</tt> command
|
||||
before uploading the file. The absolutely failsafe thing to do is to <tt>
|
||||
ssh</tt> into <tt>shell.sf.net</tt> and do the <tt>chmod</tt> there.
|
||||
The files also need to have general read permission, and any
|
||||
directories should have general execute permission and the "set user or
|
||||
group ID on execution" (s) bit should also be set. If you're not
|
||||
touching any directories, you can do it all with one command, e.g.
|
||||
<pre>
|
||||
ssh david_abrahams@shell.sf.net "chmod a+r,g+rw /home/groups/b/bo/boost/htdocs/more/updating_the_website.html"
|
||||
</pre>
|
||||
</li>
|
||||
</ul>
|
||||
<hr />
|
||||
|
||||
<p>Revised <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B,
|
||||
%Y" startspan -->$Date$
|
||||
<!--webbot bot="Timestamp" endspan
|
||||
i-checksum="38708" --></p>
|
||||
|
||||
<p>© Copyright David Abrahams 2005</p>
|
||||
|
||||
<p>© Copyright Rene Rivera 2005</p>
|
||||
|
||||
<p>Distributed under the Boost Software License, Version 1.0. (See
|
||||
accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy
|
||||
at <a href=
|
||||
"http://www.boost.org/LICENSE_1_0.txt">www.boost.org/LICENSE_1_0.txt</a>)</p>
|
||||
</body>
|
||||
</html>
|
@ -1,7 +1,7 @@
|
||||
|
||||
# Copyright John Maddock 2005. Use, modification, and distribution are
|
||||
# subject to the Boost Software License, Version 1.0. (See accompanying
|
||||
# file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
|
||||
# Copyright John Maddock 2005. Distributed under the
|
||||
# Boost Software License, Version 1.0. (See accompanying file
|
||||
# LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
|
||||
|
||||
using quickbook ;
|
||||
|
||||
|
1176
whos_using/using.qbk
1176
whos_using/using.qbk
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue
Block a user