Anthony Williams wrote:
"Sohail Somani" <s.somani@fincad.com> 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.