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 #endif
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.
Right.
My point however was that this is no longer true, starting from g++ 4.1. _REENTRANT is now being set properly (and ignored by Boost.Config).
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 into that.
(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? John.