From: Jeff Garland (jeff_at_[hidden])
Date: 2005-08-20 12:23:25
On Thu, 11 Aug 2005 17:22:23 +0100, John Maddock wrote
> > I'm tempted to just build single/multi thread variants of all libs just
> > like
> > the default build, but my question is, for which libs does multi-threading
> > actually matter? Is there a subset of boost libs that actually change
> > behavior with this switch? I'd like to get a minimal set.
> Looks like regex and serialisation depend on BOOST_HAS_THREADS, but
> shared_ptr does as well, which means date_time, filesystem,
> iostreams, program_options, python, spirit, test, and wave as well.
Just to add a small complication, the only direct use of BOOST_HAS_THREADS in
date-time is to call re-entrant versions of clock functions if they exist on
the platform. There is new code in 1.33 that uses shared_ptr so obviously
that will impact things. However, all the code that depends on
BOOST_HAS_THREADS is inline so there is no difference in the built library.
Not sure how that should be handled.
Note: By dumping old compiler support I may eliminate the need for a compiled
library in a future release. In 1.33 the only capabilities that actually
require the built library are the to_string() and serialization code (which
uses to_string()). If you stick to operator<< and operator>> you don't need
the built library even in 1.33.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk