From: John Maddock (john_at_[hidden])
Date: 2008-04-11 12:21:10
Peter Dimov wrote:
> Yep. But won't this code in suffix.hpp:
> #if (defined(__MT__) || defined(_MT) || defined(_REENTRANT) \
> || defined(_PTHREADS)) && !defined(BOOST_HAS_THREADS)
> # define BOOST_HAS_THREADS
> turn it back on?
No, well actually yes, but since there is no available threading API,
(BOOST_HAS_PTHREADS not set), it'll get turned off again...
> I admit that the task of setting BOOST_HAS_THREADS is pretty hard.
> But the current practice of distributing the setting into
> compiler/platform/suffix headers seems too fragile to me. I'm not
> sure I understand all the subtle details yet though.
The trouble is - there ain't no easy way - strictly IMO of course!
I accept it's often hard to work out what's setting what macro where - but
the alternative is a big bunch of spaggetti code to handle all the
platforms/compilers in one go, which isn't necessarily better.. or worse :-(
>> Yeh, g++ has always been lax about advertising whether it's in
>> thread safe mode or not.
> My point however was that this is no longer true, starting from g++
> 4.1. _REENTRANT is now being set properly (and ignored by
Is it? Threading support on Linux should only be turned on when _REENTRANT
is set, there might be issues on other platforms though... I'll have to look
> (Unfortunately intel-linux still emulates the older g++ practice of
> always setting _REENTRANT.)
>> Lets see where these changes get us, and then we need to decide what
>> to do on Win32 in strict mode when <windows.h> is unavailable :-)
> I believe that the fact that <windows.h> is unavailable (this can
> happen in non-strict mode as well under VC++ Express, if the Platform
> SDK hasn't been installed) should be indicated by a new macro that is
> documented as such.
Well we have BOOST_DISABLE_WIN32 which is set when <windows.h> is
unavailable - or alternatively optionally by the user.
> There's also the general problem of using BOOST_DISABLE_THREADS inside
> Boost.Config to communicate lack of threading support from one header
> to another. I don't necessarily view this as unacceptable... as long
> as Boost.Config is unquestionably right to do so; that is, as long as
> there is no situation in which the user would want to not define it.
> Still, the easiest way out is just to use an internal macro for
> communication and leave BOOST_DISABLE_* as pure user macros.
If we stop setting BOOST_DISABLE_THREADS when BOOST_DISABLE_WIN32 is set
this issue become moot doesn't it?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk