From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-01-05 14:38:22
Anthony Williams wrote:
> "Peter Dimov" <pdimov_at_[hidden]> writes:
>> Anthony Williams wrote:
>>> The problem is a combination of things.
>>> boost/config/compiler/visualc.hpp defines BOOST_DISABLE_WIN32 if
>>> extensions are disabled, presumably since windows.h relies on
>>> Microsoft compiler extensions. boost/config/suffix.hpp then defines
>>> BOOST_DISABLE_THREADS if BOOST_DISABLE_WIN32 is defined and
>>> BOOST_HAS_PTHREADS is not; the implication is that if you can't use
>>> the Windows headers, then you can't use the Windows thread API, so
>>> if we haven't got pthread-win32 configured, you can't use Boost
>> This is incorrect for two reasons. One, you don't have to include a
>> windows header in order to use Boost.Threads. Two, the fact that a
>> translation unit is built with /Za doesn't automatically make this
>> unit single threaded; libraries that depend on BOOST_DISABLE_THREADS
>> (or on the absence of BOOST_HAS_THREADS) to disable their internal
>> synchronization will break. It's possible to spawn threads without
>> including a windows header.
> Agreed; I was just highlighting the status quo. I find it strange that
> BOOST_DISABLE_THREADS is defined under these conditions, and would
> rather it wasn't.
Thinking about it a bit more, there is a third reason that Boost.Config
shouldn't be doing that. BOOST_DISABLE_THREADS is a user macro, and the
config system shouldn't be touching it.
The easiest solution is to ignore Boost.Config until the meanings of
_HAS_THREADS and _DISABLE_THREADS are sorted out and check everything at the
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk