-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock
Actually it's defining BOOST_DISABLE_THREADS and BOOST_DISABLE_WIN32 already, so scrub that request. I understand what you're saying about putting threading in the another TU, but the point is that the code we're compiling right now (this TU) can't include any threading API's (as far as Boost is concerned anyway).
Is there any reason why we can't change all direct calls to Windows API functions to calling convention thunks in another translation unit? E.g. // shared_ptr.hpp #include "boost/windows/ccthunk.hpp" windows::interlocked_increment(p); // ccthunk.hpp namespace windows { long interlocked_increment(long* volatile p); } // ccthunk.cpp #include "windows.h" namespace windows { long interlocked_increment(long* volatile p) { return InterlockedIncrement(p); } } We wouldn't to do this for the entire Win32 API, and it seems like an inversion of principles to disable functionality on a compiler because it rejects non-standard syntax (calling convention keywords). Calling convention keywords don't even fit into the C++ grammar (such information should properly be handled by pragmas--whose explicit purpose is to pass extra-linguistic information or instructions to the compiler). Regards, Paul Mensonides