From: Andreas Huber (ah2003_at_[hidden])
Date: 2003-05-02 16:10:16
Peter Dimov wrote:
> John Maddock wrote:
>>> No, the compiler is not at fault, it still defines _MT properly in
>>> The problem is that visualc.hpp defines BOOST_DISABLE_WIN32 when it
>>> sees /Za, and then suffix.hpp defines BOOST_DISABLE_THREADS when it
>>> sees BOOST_DISABLE_WIN32. The end result seems incorrect. I don't
>>> know why this is done or how it should be fixed.
Thanks for tracking this down!
>> Last time I checked you can't compile windows.h when in ANSI mode -
> Why should this affect BOOST_HAS_THREADS? A program can use threads
> without ever including windows.h.
>> let me know what behaviour is correct and I'll try and patch the
> I don't know. I'm not sure what BOOST_HAS_THREADS is supposed to mean.
I don't know either. However, I think this is a severe problem that should
be fixed as soon as possible. Multithreaded programs compiled with /Za on
MSVC could be haunted by rather ugly and hard-to-find bugs as a result of
The following snippet has been in visualc.hpp for almost a year (added with
// disable Win32 API's if compiler extentions are
// turned off:
# define BOOST_DISABLE_WIN32
This seems to be correct, at least 7.1 fails to compile windows.h with /Za.
However, the following lines in suffix.h lead to BOOST_HAS_THREADS being
undefineed later (also added with V1.13 a year ago):
// If Win32 support is turned off, then we must turn off
// threading support also, unless there is some other
// thread API enabled:
#if defined(BOOST_DISABLE_WIN32) && defined(_WIN32) \
&& !defined(BOOST_DISABLE_THREADS) && !defined(BOOST_HAS_PTHREADS)
# define BOOST_DISABLE_THREADS
This seems a bit suspicious to me. As Peter has already pointed out: Not
being able to compile windows.h does not necessarily mean that there can't
be multiple threads. The problem arises when /Za compiled client code uses a
third party threading library (which itself was compiled without /Za) and
*additionally* includes header-only libs like shared_ptr.hpp. shared_ptr
objects will then *not* use a mutex although there could clearly be multiple
threads accessing it simultaneously.
It seems this could be fixed by deleting the above lines and making the
windows.h including code (boost/threads, ???) check for BOOST_DISABLE_WIN32?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk