From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-04-13 11:55:04
> 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
> 4) In irix.hpp for versions of gcc that can't be built multithreaded
> 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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk