Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2007-02-26 10:55:59

I don't know if everyone saw this post and the *long* ensuing thread
(I have been away from the NGs for the past month or so) but IMO it's
very important for us (I mean the authors and maintainers of the
referenced libraries) to address posts like this one, both to show our
responsiveness but also to counter the inevitable FUD that ensuses when
such posts are not answered.

attached mail follows:

{ Mod note: I'm accepting this article because the issues raised here,
essentially the quality of specific parts of the Boost library, seem to
be of general interest to the C++ community. -mod/aps }

A few months ago, in comp.lang.c++.moderated, Wil Evers pointed out
some problems in a few Boost libraries (below). Since we are
considering using all of the libraries mentioned (and also
Boost.Threads and Boost.uBlas), I wonder if these problems have been

I've looked at Boost-developers archives, where this message was
forwarded. It seems that only the protability of Boost.Test lead to
some discussion.

BTW, what's a header race? The order of #inclusion or linking affecting
program behavior?


Wil Evers wrote:

>> [...] For some of the Boost libraries, we've actually
>> decided
>> to phase out their use at the first available opportunity. These
>> are:

>> filesystem
>> program_options
>> serialization
>> test


I'll be specific (all targeted at the official boost-1.33.1 release) :

1) filesystem:

- Major problems interfacing with the native API on one our targets
Alpha); unmaintainable Boost source, so we couldn't implement any
reasonable workaround
- Uses inherently thread-unsafe function-local statics

2) program_options:

- Some functions in the public API, used in the examples in the
documentation, dropped without any explanation

3) serialization

- A header race; doesn't tolerate including <boost/shared_ptr.hpp>
- Yet another header race involving headers in both boost/archive and
boost/serialization; details on request

4) test (please don't get me started)

- Way too intimate with its developer's apparently native platform
for any reasonable degree of portability (takes over main(), maps OS
signals to C++ exceptions, continues to run after failing assert()s,
- Lots of construction/destruction ordering issues - major changes here

between boost-1.32 and boost-1.33.1


- Wil

      [ See for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at