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. Jeff 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.