Peter Dimov wrote:
John Maddock:
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.
I don't like the fact that the macro names do not reflect their actual meaning. This inevitably leads to their being set in situations where they shouldn't be, and vice versa. A macro that indicates the absence of windows.h should be called BOOST_NO_WINDOWS_H, and the reverse should be BOOST_HAS_WINDOWS_H. A user macro that overrides the detection should be called BOOST_DISABLE_WINDOWS_H. In general, we should follow a consistent naming scheme.
You right after I posted that I thought: "Doh! Should have suggested BOOST_HAS_WINDOWS_H".
It's obvious when this macro should and should not be set, and it's obvious when it needs to be tested - when the code decides whether to #include <windows.h> or not.
The problem with making the macro clear and unambiguous in this manner is that it exposes that libraries - in reality - have no use for 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?
There are other places where BOOST_DISABLE_THREADS is being set by Boost.Config. The problem is that I can't really know whether they are correct or not - from user point of view.
The good thing about testing a user macro is that one is 100% certain that the user means what he says; the library better do what it's being told.
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? John.