Re: [boost] Boost threads + MSVSC + /Za + client code

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 
direction.)

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 
language extensions).

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.

Roland