Re: [boost] BOOST_DISABLE_WIN32

From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-04-13 11:55:04

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.)