What is Boost?

Safe, generic container for single values of different value types, from Kevlin Henney.

STL compliant container wrapper for arrays of constant size, from Nicolai Josuttis.

Generalized binders for function/object/pointers and member functions, from Peter Dimov.

Defines types for passing parameters, from John Maddock, Howard Hinnant, et al.

Help for non-conforming standard libraries, from Ralf Grosse- Kunstleve and Jens Maurer.

Functional composition adapters for the STL, from Nicolai Josuttis.

Empty member optimization, from John Maddock, Howard Hinnant, et al.

Tools for generic programming, from Jeremy Siek.

Helps boost library developers adapt to compiler idiosyncrasies; not intended for library users.

Numeric, polymorphic, and lexical casts, from Dave Abrahams and Kevlin Henney.

Cyclic Redundancy Code, from Daryle Walker.

Function object wrappers for deferred calls or callbacks, from Doug Gregor.

Enhanced function object adaptors, from Mark Rodgers.

Generic graph components and algorithms, from Jeremy Siek and a University of Notre Dame team.

Headers to ease dealing with integral types.

Adapt a base type into a standard conforming iterator, and more, from Dave Abrahams, Jeremy Siek, and John Potter.

Several contributions in the domain of mathematics, from various authors.

Greatest common divisor and least common multiple, from Daryle Walker.

Octonions, from Hubert Holin

Quaterions, from Hubert Holin.

Mathematical special functions such as atanh, sinc, and sinhc, from Hubert Holin.

Templates ease arithmetic classes and iterators, from Dave Abrahams and Jeremy Siek.

Memory pool management, from Steve Cleary.

Preprocessor metaprogramming tools including repetition and recursion, from Vesa Karvonen.

Concepts defining interfaces which map key objects to value objects, from Jeremy Siek.

Reflects C++ classes and functions into Python, from Dave Abrahams.

A complete system for random number generation, from Jens Maurer.

A rational number class, from Paul Moore.

Regular expression library, from John Maddock.

Four smart pointer classes, from Greg Colvin and Beman Dawes.

Static assertions (compile time assertions), from John Maddock.

Support for program testing and execution, from Beman Dawes.

Portable C++ multi-threading, from William Kempf.

Event timer, progress timer, and progress display classes, from Beman Dawes.

Break of a string or other character sequence into a series of tokens, from John Bandela.

Ease definition of functions returning multiple values, and more, from Jaakko Järvi.

Templates for fundamental properties of types, from John Maddock, Steve Cleary, et al.

Class noncopyable plus checked_delete(), checked_array_delete(), next(), prior() function templates, plus base-from-member idiom, from Dave Abrahams and others.

Beman: It has created a community of C++ library users and developers.

Dave: Boost is one of the only communities working on the process and practice of library design. In today's professional software development world, it can be hard to make the case for long-term investment in reusable components. Developers are (often rightly) expected to do the simplest thing that could possibly work, under the assumption that the generalization won't be needed. As the problems they need to solve become more complex, however, they need library components that can help them keep their solutions simple. The C++ standard library goes some distance towards filling that role, but programmers will continue to need more than it provides. What should be the design, documentation, and coding practices for the libraries that programmers need? Boost's emergent collaborative process provides one answer.

Jens: First and foremost, Boost gives examples how C++ libraries should be designed. There are lots of libraries available elsewhere whose design pre-dates the ISO C++ standard. These libraries often fail to exploit the potential of compile-time evaluation (i.e. templates) and thus miss type checking and optimization opportunities. Furthermore, these libraries are occasionally difficult to extend or poorly documented.

Second, Boost produces ready-to-use, well-documented, highquality libraries from the practice of programming. The license requirements allow the use of Boost libraries in commercial and non-commercial projects free of charge, thereby helping them to produce better programs.

Third, Boost is a test-bed for components that may end up in a future revised C++ standard. I am proud to be part of a respected effort with worldwide recognition.

Fourth, Boost attracts some of the best C++ programmers in the world. Its open discussions and peer-reviews cause every participant to learn quite a lot.

Jens: The small things: Smart pointers, utility.hpp, "functional", probably "any" and "function"

Beman: The potential for Boost libraries goes way beyond the C++ Standards effort. Standardization of some of the Boost libraries may help validate the Boost concept, but just plain user interest is really important too. As long as users ask for new libraries, and developers are willing to write them, Boost will grow and prosper.

Dave: Yes, I'm sure it will continue. Boost's value to the C++ community goes well beyond standardization.

Dave: I think most talented programmers - in any language - love to collaborate and are dying to work with others of similar caliber. A really good programmer craves thoughtful and careful review of his code, useful feedback and ideas about design alternatives. That sort of environment can be hard to find, especially If you are at the top of your game in your daily work. The process we've established at Boost and the highly professional tone of the discussion give the best programmers what they crave, and gives others a path to reaching that level.

Jens: Boost has an open discussion policy. Its peer-review atmosphere, well established in the scientific community, fosters learning for every participant. Plus, we've had the luck to distribute very little off-topic e-mail in the mailing list so far, and we as the moderators try our best so that it will stay that way. Also, Boost library authors and maintainers are asked to acknowledge contributions, another wellestablished behaviour in the scientific and open-source communities. This gives contributors a permanent record to put pride in.

Dave: I can think of four reasons:

0. Would you rather write it yourself? The Boost libraries are time-savers and code-savers. You'll spend less time developing your application and have less code to maintain if you can re-use the appropriate Boost library.

1. Quality. Most of the boost libraries have had a more thorough review by more talented and critical eyes than I've ever seen in a commercial environment.

2. Open Source. If you absolutely need to change the library to suit your own application, the source is all there.

3. Tests. No boost libraries are accepted without a comprehensive test suite, and all are tested against a wide variety of platforms and compilers.

Jens: No. We may have to adjust our organization to cope, though.

Dave: Several interesting and ambitious libraries seem to be on the immediate horizon. There is a template metaprogramming library that brings STL-like algorithms and functional programming idioms to compile-time computation, we have an effort to develop next-generation linear algebra and matrix computation, and the developers of the Spirit parsing framework have expressed an intention to "Boostify" soon.

Beman: More of the same; more libraries, more interesting discussions. It all depends on the C++ programmers who are members of Boost, but there is no sign of interest leveling off. Every measure we have continues to show strong growth. Quality of new libraries being submitted seems strong. The future looks bright!

Dave: One of the best things about Boost is the way that the participants generate its direction, and only when enough people are sufficiently committed to pull it off. For example, in the past week a group of dedicated Boosters who straddle the developer/user line set up a separate mailing list and a Wiki for Boost users. I am convinced that this couldn't have happened if the boost moderators had tried to spearhead the effort.

Dave: As shown by the spontaneous creation of the users list and Wiki, when Boost begins to grow beyond its capacity, I expect it to reorganize. We have been discussing different ways to enable better collaboration as this happens: we want to have the required knowledge when the time comes, but I think we've learned not to try to plan too far in advance.

Jens: We may have separate moderators for library subcollections, e.g. for the maths and numerics libraries. We may have to split the mailing list further, though there are good arguments against doing so. Namespaces in C++ and directories in the file system are hierarchical, so we have all the tools we need to effectively sub-divide organizationally.

Jens: I think so. Not all members cast a vote on every submission, and it is assumed that members casting a vote have had a look at the library before. Also, the review manager is entitled to disregard votes that are cast without observing the review guidelines.

Jens: Boost meets every half a year on the Sunday afternoon before the ISO C++ meeting starts, at the same place than the ISO C++ meeting.

Dave: Definitely a lucky side effect. I guess that's what happens when you provide services and code that people want.

Jens: For me, it's part of the intent.

[Author's note: Select the answer that you like!]

Beman: If the company doesn't normally have support agreements for software libraries of about the same scope as Boost, they probably don't need a support agreement for Boost either. If the company does want a support agreement, they should ask their usual support contractors for Boost support. I know several folks at one of the support companies, and they would be perfectly capable of supporting the Boost libraries.

Dave: Re-use first; rewrite if necessary. In other words, start by using the boost libraries to achieve short time-to-market with high quality. If independence from open source is important to your longterm mission, you can always go back and replace boost components with internally developed and maintained ones.

Jens: Other open-source projects (e.g. Linux) have shown that when there's money being offered, someone shows up offering support for the project. I'm confident that some of Boost's members would take a support contract when one was offered.

Dave: So far, making it possible for users to cover more domains with cross-platform code has been our main focus. Although many libraries seem to fit the bill for addition to the standard, a few are less likely candidates. We have also made occasional concessions to nonconforming compilers and compilers that don't implement all of the optimizations one would like, because these things have practical importance for users. One would not expect to see such concessions to appear in the C++ standard library, however. As the C++ committee prepares to start considering what the next version of C++ will look like, standardization will likely increase in importance.

Beman: The issues really go hand-in-hand. Well-developed, widely used libraries benefit both users and the C++ Standard. Users get the use of the libraries, while the standards committee gets "existing-practice" to standardize, and that is what standards committees do best. That leads to a better standard, which in turn benefits users. The circle is closed.

Jens: I agree, there isn't a clear separation between these two aims: The next C++ standard is also aimed at providing added value to users. For me, adding value to users is the major aim of Boost; be it directly (and rather short-term) or indirectly by impacting the next C++ standard. Formal standardization has the advantage of broad recognition even in non-technical circles, but takes longer to produce results.