views:

425

answers:

1

I just discovered that when Language Extensions are disabled in MSVC, you get this error if you try to include boost/thread/thread.hpp:

fatal error C1189: #error : "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS"

It seems that when Boost detects that language extensions are disabled (_MSC_EXTENSIONS isn't defined), they define BOOST_DISABLE_WIN32, to indicate that it is not safe to include windows.h (which won't compile without extensions enabled).

And as a consequence of that #define, BOOST_DISABLE_THREADS is defined, even though Boost.Thread isn't a header-only library, and windows.h is only included in the .cpp files. The headers should in principle be safe to use without language extensions. All the actual win32 calls are isolated in the compiled library (the .dll or .lib)

I can see here that they're aware of the problem, but as it's remained untouched for the last two years, it's probably naive to hope for a quick fix.

It seems like it should be a fairly simple case of modifying some of the #ifdef's and #defines in the various Boost configuration files, but there are a lot of them, and they define and use a lot of macros whose purpose isn't clear to me.

Do anyone know of a simple hack or workaround to allow inclusion of the Boost.Thread headers when language extensions are disabled?

+2  A: 

I don't see any simple way to turn off the behavior.

You could wrap the block with your own #ifdef starting at boost\config\suffix.hpp(214):

#ifndef TEMP_HACK_DONT_DISABLE_WIN32_THREADS // XXX TODO FIXME

#if defined(BOOST_DISABLE_WIN32) && defined(_WIN32) \
   && !defined(BOOST_DISABLE_THREADS) && !defined(BOOST_HAS_PTHREADS)
#  define BOOST_DISABLE_THREADS
#endif

#endif // ndef TEMP_HACK_DONT_DISABLE_WIN32_THREADS

Not a perfect fix, but it should be temporary until you can get them to fix it upstream. The boost stuff is good, but it's not immutable in its perfection.

Of course, make some kind of tracking item so you don't lose track of your divergence from upstream.

Marsh Ray
hmm, just tried it out. I then get errors in thread_time.hpp instead.Thanks though, but it seems to require a bit more boost hackery to get working. Maybe I'll just admit defeat and either install pthreads for windows (another dependency, ugh), or enable language extensions.
jalf
I've tried to run without language extensions myself, but found it impractical. It's hard to write a significant program for Windows without "windows.h". It's better than it used to be, MS split some of the more egregious extensions out into separate compiler switches.I would avoid adding a pthreads implementation to a windows app to solve a header file issue.The boost/thread/win32 subdirectory contains some heroic efforts to work without "windows.h". It does seem odd that you can't effectively use it.
Marsh Ray
I don't *in general* have a problem working without language extensions. Windows.h can be easily wrapped in a separate translation unit (with language extensions enabled), but obviously, it relies on libraries like boost.thread working without them. Which doesn't seem to be the case unfortunately.
jalf