Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-09-24 15:04:29


--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "William Kempf" <williamkempf_at_h...>
> > It's correct as written. The macro BOOST_DISABLE_THREADS is used
to
> disable
> > Boost thread support even if the config stuff detects that thread
support
> is
> > enabled for the compiler/platform.
>
> (cc: to the list)
>
> Look at the context:
>
> //
> // Turn on threading support if the compiler thinks that it's in
> // multithreaded mode. We put this here because there are only a
> // limited number of macros that identify this (if there's any
missing
> // from here then add to the appropriate compiler section):
> //
> #if (defined(__MT__) || defined(_MT) || defined(_REENTRANT) \
> || defined(_PTHREADS)) && !defined(BOOST_DISABLE_THREADS)
> # define BOOST_HAS_THREADS
> #endif
>
> //
> // Turn threading support off if BOOST_DISABLE_THREADS is defined:
> //
> #if defined(BOOST_DISABLE_THREADS) && defined(BOOST_HAS_THREADS)
> # undef BOOST_HAS_THREADS
> #endif
>
> --
>
> BOOST_DISABLE_THREADS is handled separately by the second block; if
> BOOST_HAS_THREADS is already defined (the first comment implies
that this is
> possible) the first #define causes a redefinition.
>
> At least this is my understanding of it.

Sorry, I didn't write this stuff and didn't look close enough ;).
However, I think it's still correct as is. I *believe* that certain
compilers always have threading support "turned on" (gcc is one such
compiler, isn't it?), and so the compiler portion of the config
system defines BOOST_HAS_THREADS. Since none of the "magic macros"
in the first section will exist in this case BOOST_HAS_THREADS is
never redefined. The !defined(BOOST_DISABLE_THREADS) in the first
portion is superflous because of the second portion, but it's not
really incorrect. I'd say you could safely remove it in the first
portion if it causes confusion, but it's technically still correct as
is.

Bill Kempf


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