Hi, while I was trying to compile my project with boost trunk I saw several warnings coming from Boost.Thread. These are always shown: ...\boost/thread/win32/thread.hpp(183) : warning C4251: 'boost::thread::thread_info_mutex' : class 'boost::mutex' needs to have dll-interface to be used by clients of class 'boost::thread' ...\boost/thread/win32/mutex.hpp(20) : see declaration of 'boost::mutex' ...\boost/thread/win32/thread.hpp(184) : warning C4251: 'boost::thread::thread_info' : class 'boost::intrusive_ptr<T>' needs to have dll-interface to be used by clients of class 'boost::thread' with [ T=boost::detail::thread_data_base ] Additionally, these are shown with /Wp64: ...\boost\thread\win32\basic_timed_mutex.hpp(36) : warning C4312: 'type cast' : conversion from 'long' to 'void *' of greater size ...\boost\thread\win32\basic_timed_mutex.hpp(142) : warning C4311: 'type cast' : pointer truncation from 'void *const ' to 'long' ...\boost\thread\win32\basic_timed_mutex.hpp(142) : warning C4312: 'type cast' : conversion from 'long' to 'void *' of greater size ...\boost/thread/win32/thread.hpp(530) : warning C4267: 'return' : conversion from 'size_t' to 'int', possible loss of data ...\boost/thread/win32/condition_variable.hpp(58) : warning C4244: '=' : conversion from '__w64 int' to 'unsigned int', possible loss of data I believe, 4251 can be safely disabled with #pragma (along with 4275 if it comes up somewhere I didn't notice). In case of 4267 it seems like the return type should rather be changed. As for others, most of them come from interlocked macros and probably could be disabled as well, although the casting pointers to integers bugs me. I haven't checked the 1.35 RC branch but if the issue persists there too, I'd like to ask to make the release warning-free too. I guess, a couple of #pragmas won't break anything. And I have some other notes: 1. I found BOOST_STATIC_CONSTANT macro usage in some places. On VC 7.1+ it expands into a static constant member which has to be defined in a namespace scope despite of that it's a compile-time constant. Nevertheless, these members are not defined. I know that MSVC just works without it but strictly speaking this is not C++ compliant. Since these constants are members of non-template classes I would suggest to use enums instead of the macro. 2. VC 8.0 and later has _ReadBarrier and _WriteBarrier in addition to _ReadWriteBarrier. These could be used in interlocked_read.hpp. 3. There are tabs in win32/mutex.hpp:21 4. There is a potential memory leak in win32/thread.hpp:480. If the push_back throws the thread object is leaked. Remarkably, the pthread version is safe since it uses auto_ptr.