From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-01-03 03:46:08
"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
OTOH, someone put the restriction there for a reason, and I wouldn't want to
remove it without careful thought.
-- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk