From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2007-01-05 03:52:56
Anthony Williams wrote:
> I am not sure what we can do about this. One issue is that currently the
> thread lib requires windows.h, and therefore compiler extensions, when the
> library sources are built. I'm not sure whether it is safe to link something
> compiled with extensions on against something compiled with extensions off ---
> is the ABI the same?
I am pretty much sure it is. Otherwise it would be impossible to link a
library, which even might be produced by a compiler of a different laguage.
> If it *is* safe, then we should remove this define from
> boost/config/suffix.hpp, since the boost thread headers don't explicitly
> include windows.h.
Hmm, true for the current version, but if we go header only in future?
> OTOH, someone put the restriction there for a reason, and I wouldn't want to
> remove it without careful thought.
I always thought it was a bad idea for the Boost.Thread to explicitly
depend on these macros when invoked from client builds. If you look into
my platform split of the thread_rewrite branch you will see, that I have
tried to not rely on these, and as it turns out now this is a good
thing. (Altough it does not go yet all the way, just pointing the
The client code might be interested which threading API is available
_if_ it is going to make use of it. If Boost.Thread is being used the
client code needs not know (and should be able to compile without
Another issue is the semantics of BOOST_HAS_THREADS:
Does it mean
1) No OS threading API available or
2) No threading at all ?
I currently see it as 1). You still should be able to use Boost.Thread.
Then when client code defines: BOOST_DISABLE_THREADS the implementation
of Boost.Thread could make use of this information and replace
everything that makes sense with stubs. It does not make sense to stub
out the thread launching API, but it makes sense for the locking API.
Thread launching should give a compile error in this case. This would
allow library users to write MT aware library code without #idefing when
used in a single thread context.
All this does not help much in the current implementation, and I would
not attempt to change any of these short before release. But we
definitely should do it for the next release!
Sorry for my whining, but I have to reiterate:
We should _not_ try to do as much as possible header only. This issue is
just another bullet on my list why we should not.
I agree there are lot of things which require header only, but we should
try to do as much as possible using the library mechanism.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk