[boost] Missing BOOST_HAS_THREADS on MSVC with /Za and /MT (was: Re: MSVC7.1 config problems ...)

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
>>> /Za
>> mode.
>>> 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
>> config....
>
> 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
this.

Specifically:

The following snippet has been in visualc.hpp for almost a year (added with
V1.13)

//
// disable Win32 API's if compiler extentions are
// turned off:
//
#ifndef _MSC_EXTENSIONS
#  define BOOST_DISABLE_WIN32
#endif

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
#endif

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?

Thanks,

Andreas