Boost logo

Boost :

From: BRIDGES Dick (Dick.Bridges_at_[hidden])
Date: 2005-06-22 16:10:56

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On
> Behalf Of John Maddock
> Sent: Wednesday, June 22, 2005 4:02 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Boost.config not recognize threading support
> > - BOOST_HAS_PTHREADS is defined in posix_features.hpp after
> > is included. I had hoped this was a good thing. ;)
> Yes.
> Yes: for some compilers (including gcc on some platforms), just
because the
> platform has pthreads, and advertises it's presence in unistd.h, this
> *not* mean that the C++ compiler can generate thread aware/safe code
> special measures are taken (a special command line option usually, for
> example -mthreads on cygwin), or not at all in some cases (gcc on SGI
> for example). C++ compiles have to take special care when generating
> exception handling and / or RTTI code that may involve hidden globals,
> order for them to be thread safe. This is not the case for C
compiles, and
> remember that unistd.h is a C header!
> Failing everything else, I think the way to handle this is with
> like this in libstdcpp3.hpp:
> #if defined(macro-that-identifies-linux-on-arm) &&
> #endif

[Dick] My primary reservation about this approach is based upon my
assumption that the "macro-that-identifies-linux-on-arm" would be an
attribute of the compiler. I still can't get used to the idea that
multi-threaded or single-threaded is compiled into the gcc
cross-compiler itself, while little-endian and big-endian are command
line switches. %>[ The multiplicity of targets and threading models
might require a number of such tests that would be difficult to manage.

> Any closer?

[Dick] I'm of two minds about the following suggestion: it's either a
kludge or introduces a certain pleasing symmetry. ;)

Since BOOST_DISABLE_THREADS is used to unconditionally disable threads,
the user-wielded imperative BOOST_ENABLE_THREADS (tested at the same
place in suffix.hpp) would [almost] unconditionally define
BOOST_HAS_THREADS - subject only to the existing verification that the
threading API has been identified and is recognized.

For compilers that do not provide detectable compile-time indications
that threading is enabled, this seems to me to be a fairly
straight-forward and minimally invasive adaptation. Although this puts
the onus on the user, it does have the advantage of being independent of
the target and potentially stable.

> John.

[Dick] Regards,

Boost list run by bdawes at, gregod at, cpdaniel at, john at