Peter Dimov wrote:
John Maddock wrote:
Doug, what effect would none of BOOST_HAS_WINTHREADS, BOOST_HAS_PTHREADS and BOOST_HAS_THREADS being defined have on shared_ptr?
Well.
BOOST_HAS_THREADS is an overloaded macro. It can mean one of two things:
1. Whether the compiler/runtime is in multithreaded mode. In this case, the absence of BOOST_HAS_THREADS would indicate that the compiler/runtime only supports a single thread, and hence, a library may use that to safely disable synchronization.
2. Whether a threading API is available. In this case BOOST_HAS_WINTHREADS and BOOST_HAS_PTHREADS provide additional information about which API is available.
The problem is that BOOST_HAS_THREADS isn't very useful in practice, no matter what meaning is chosen. Its absence cannot be used to assume a single thread (because it gets turned off when there's no threading API), and it cannot be used to assume lack of threading API (because of BOOST_DISABLE_WIN32.)
So shared_ptr ignores it as much as it can.
:-( So the question becomes, how do you want these macros to behave? John.
To get back to your question, BOOST_HAS_WINTHREADS is not used by shared_ptr, so it doesn't matter whether it's defined or not.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost