Anthony Williams wrote:
"Peter Dimov" <pdimov@mmltd.net> 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 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 library level.