Re: [boost] Boost threads + MSVSC + /Za + client code

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-01-05 15:36:30

Sohail Somani wrote:
>> [mailto:boost-bounces_at_[hidden]] On Behalf Of Peter Dimov
>
>> 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.
>
> Hey, this sounds awesome. So you seem to be suggesting that
> Boost.Config should not touch *_THREADS until we sort out the meaning
> of those?

I was suggesting that it would be easier to just make Boost.Threads work 
instead of fixing Boost.Config. But now that I looked at the code, it 
doesn't really seem that much easier. There is a comment in win32.hpp:

// Win32 will normally be using native Win32 threads,
// but there is a pthread library avaliable as an option,
// we used to disable this when BOOST_DISABLE_WIN32 was
// defined but no longer - this should allow some
// files to be compiled in strict mode - while maintaining
// a consistent setting of BOOST_HAS_THREADS across
// all translation units (needed for shared_ptr etc).

that indicates that our past discussion (this is not the first time this 
comes up) has had an effect. Mixing /Za and /Ze still seems to result in 
inconsistent BOOST_HAS_THREADS, though. This breaks 
detail/lightweight_mutex, for example. It even seems to break Regex, there 
are a number of BOOST_HAS_THREADS checks there that use the "are we in MT 
mode" meaning of the macro, as opposed to its "do we have a threading API" 
meaning.