Re: [boost] BOOST_DISABLE_WIN32

From: John Maddock (john_at_[hidden])
Date: 2008-04-11 13:39:00

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.