Boost logo

Boost :

From: John Maddock (boost.regex_at_[hidden])
Date: 2003-08-29 06:49:51


> I was thinking of a view from the point of view of each individual
> library. e.g., the shared_ptr docs mention what to define to
> turn off thread support on a boost that was configured with thread
> support on, but I didn't see a specific explanation of what to define to
> turn thread support on without Boost Config.
>
> >> Boost Config seems to hide those details fairly effectively for
developers
> >> who don't distribute their code (or distribute Boost along with their
> > code).
> >>
> >> The problem I see is that developers who distribute code that depends
on
> >> boost can't count on the user's version of Boost being configured in
any
> >> particular way (or at all - the docs suggest just untarring it as a
valid
> >> way to use the header-only modules).
> >
> > There shouldn't really be any difference between the config after just
> > extracting the tarball, and after running configure.
>
> Maybe I'm missing something - when I run boost/libs/config/configure, it
> adds #defines to user.hpp. Presumably Boost Config does something
similar,
> correct?

Yes, the default user.hpp does nothing and delegates everything to to the
boost.config system, ultimately they should both end up setting the same
options allbeit by different means.

> If these defines were just for boost implementation details/optimization
it
> wouldn't concern me, but it seems as though in some cases they change the
> way Boost will interact with my program (e.g., shared_ptr and thread
safety).

Threading support is on when BOOST_HAS_THREADS is defined, and off when it's
not, or forced off by defining BOOST_DISABLE_THREADS, you'll find both of
these mentioned in the configure generated user.hpp (and in the config
docs).

John.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk