Boost logo

Boost :

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(
# 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, gregod at, cpdaniel at, john at