From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-01-03 09:02:11
"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 threads.
> 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
However, someone put the checks in there, and must have done for a reason, so
just changing it would seem like a bad idea, unless we have suitable tests to
verify that it's OK.
Looking at the history, this check has been there since John Maddock added it
in May 2002 for release 1.28.
-- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk