$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: williamkempf_at_[hidden]
Date: 2001-09-24 15:21:56
--- In boost_at_y..., Darin Adler <darin_at_b...> wrote:
> on 9/24/01 1:04 PM, williamkempf_at_h... at williamkempf_at_h...
> wrote:
> 
> > 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.
> 
> Yes.
> 
> But many preprocessors warn if you define a macro twice. So we 
might need to
> add a !defined(BOOST_HAS_THREADS) to that expression since 
BOOST_HAS_THREADS
> might already be defined.
It should be defined *ONLY* if the compiler does not support the 
concept of having thread support enabled and disabled, such as for 
gcc.  So there's no need to check !defined(BOOST_HAS_THREADS) because 
the other checks already preclude this from being defined.  In fact, 
you could argue that we want a warning if this isn't the case to help 
us insure that BOOST_HAS_THREADS is not defined by compiler/platform 
config information if the compiler supports detection through the 
various "magic macros" such as _MT, et. al.
Bill Kempf