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

From: John Maddock (john_at_[hidden])
Date: 2007-01-03 05:30:47

Anthony Williams wrote:
> "Sohail Somani" <s.somani_at_[hidden]> writes:
>
>> Any takers? The workaround I've found for the problem below is to
>> #define _MSC_EXTENSIONS before including any boost thread headers. It
>> /appears/ that this is only necessary when separately compiling boost
>> threads. Sorry for the cross-post.
>>
>>> With Visual C++, I can't seem to determine why if I simply include
>>> boost/threads/once.hpp, I need to enable language extensions for
>>> that translation unit. I'm going to dig into this further today but
>>> I would appreciate if someone has figured out a solution short of
>>> allowing language extensions. I can understand requiring it for
>>> building boost threads (as windows.h seems to have some extended
>>> syntax) but I'm not sure of the logic behind requiring client code
>>> to use it as well.
>
> 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.
>
> I am not sure what we can do about this. One issue is that currently
> the thread lib requires windows.h, and therefore compiler extensions,
> when the library sources are built. I'm not sure whether it is safe
> to link something compiled with extensions on against something
> compiled with extensions off --- is the ABI the same? If it *is*
> safe, then we should remove this define from boost/config/suffix.hpp,
> since the boost thread headers don't explicitly include windows.h.
>
> OTOH, someone put the restriction there for a reason, and I wouldn't
> want to remove it without careful thought.

Your analysis is correct.

This may prove to be a tricky one: I think we can safely link to the thread 
lib when building with /Za, but I suspect that there are other libraries 
that depend on BOOST_HAS_THREADS as well: in fact a quick search through the 
headers showed rather a lot of uses, some relate to use of Boost.Threads, 
but many don't.

I guess we could invent a new macro BOOST_HAS_THREAD_LIB or something, but 
then to be consistent, we would have to change some but not all uses of 
BOOST_HAS_THREADS in other libraries to this new macro.  Tricky to get it 
all right.

Also, haven't some of the Boost.Thread components become header only now? 
Will these still work with /Za?

Apologies for raising more questions than answers!

John.