From: John Maddock (john_at_[hidden])
Date: 2004-05-13 05:28:19
> > I think the problem here is that we have two options for the <threading>
> > variant, but really we should have three:
> > 1) threading must be on
> > 2) threading must be off
> > 3) whatever the default is for the compiler
> > Most people actually want option (3) a lot of the time,
> Actually, I just don't want to pay for MT, unless I really mean to use the
> code in MT environment.
I understand that, but we have to decide how to handle this, so that it is
actualy safe, and in particular boost headers should honor the compilers
> > and currently
> > that's what <threading>single more or less gives you, ideally though we
> > would map builds for option 3 to either 1 or 2 so we don't build
> > we've actually already built.
> I don't really understand the problem. For example, are there any
> which generate MT code by default? And, what's "default for the compiler"?
Yes, lots of them, MSVC when using a dll runtime, some Unix compilers I
believe (though I forget which ones, can probably find out if it's
important), gcc on some platforms as well.
Actually with gcc you already "pay" for threading support in the standard
lib, likewise with MSVC, if you really want it turned off in Boost, then
defining BOOST_DISABLE_THREADS will do the trick. What I'm trying to say is
that our default behaviour should be the same as the compiler and std lib in
use, any thing else will lead to confusion IMO.
> > This happens at the moment for example with
> > MSVC where <runtime-link>dynamic implies <threading>multi, and any other
> > option for the <threading> variant gets ignored.
> And what's the problem with that?
You build the same library twice - for example with MSVC the
<threading>single<runtime-link>dynamic variants are the actually the same
thing (as far as the binaries are concerned), but both get built separately
by a Boost install.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk