From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-04-11 12:53:12
>>> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk