Boost logo

Boost :

From: Andrey Semashev (andysem_at_[hidden])
Date: 2008-03-18 18:07:33


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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk