John Maddock:
Understood, looking through its set in the following cases:
1) In suffix.hpp when BOOST_DISABLE_WIN32 is set.. 2) In amigaos.hpp unconditionally: I assume there is just no (working) threading support here? 3) In hpux.hpp for versions of gcc that can't be built multithreaded there. 4) In irix.hpp for versions of gcc that can't be built multithreaded there. 5) In libstdcpp.hpp if the std lib was built single threaded.
My suspision is that all except (5) can be removed - indeed 2,3 and 4 have probably been obsoleted by (5).
IMO it doesn't seem unreasonable to set this macro in case (5) regardless of what _REENTRANT and other macros may be saying?
I agree that setting it in case (5) is reasonable. For now I've updated sp_counted_base.hpp as follows: #elif defined( BOOST_DISABLE_THREADS ) && !defined( BOOST_SP_ENABLE_THREADS ) && !defined( BOOST_DISABLE_WIN32 ) # include <boost/detail/sp_counted_base_nt.hpp> When we drop (1) I'll remove the !defined( BOOST_DISABLE_WIN32 ) test. Looking through the uses of BOOST_DISABLE_WIN32 still makes me slightly nervous though. It seems that it's sometimes (ab)used to mean "the compiler is in strict mode". I believe that strict/non-strict modes are link compatible, and indeed, it's common for strict mode users to compile everything in strict mode except the few platform-specific translation units where <windows.h> is included. Testing for BOOST_DISABLE_WIN32 in Boost may well lead to ODR violations in these cases. The same is true for the other typical use where a CRITICAL_SECTION is optimized out when BOOST_DISABLE_WIN32 is detected. (A "safe" CRITICAL_SECTION that I believe works in strict mode is provided by detail/lightweight_mutex.hpp, by the way.)