"Sohail Somani" 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. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk