Re: [boost] boost/config/suffix.hpp: spuriousBOOST_HAS_THREADSwithg++ 3.4

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-05-18 07:13:43

John Maddock wrote:

> > 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
> default setting.

I think I'm confused over what's "default setting" is, and if it important. I 
think the point is that 
1. User should be able to specify if boost libraries should be thread-safe
2. He should do this with a minimum of effort. This is especially important 
for compile-only library

So, if compiler has an option to tell if application should be build in MT 
mode, *that option* should affect thread safety of boost libraries. It's 
actually not very related to MT-safety of standard lib.

> > I don't really understand the problem. For example, are there any
>
> compilers
>
> > which generate MT code by default? And, what's "default for the
> > compiler"?
>
> Yes, lots of them, MSVC when using a dll runtime, 

Do you mean, when using /MD switch? But I believe default switch is /ML?
So, there are two switches which mean "I'm building MT code": /MT and /MD, but 
none of those are default.

> some Unix compilers I 
> believe (though I forget which ones, can probably find out if it's
> important), gcc on some platforms as well.

Ok, on those platform we'd need to be thread-safe uncondionally.

> Actually with gcc you already "pay" for threading support in the standard
> lib, 

But that might be not so much, compared to say, locking in every place where 
shared_ptr is used in code.

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

Quite the contrary, I think we need to respect compiler switches, but not 
library settings. Anyway, this is only important if we can get gcc to 
reliable report -pthread presense.

> > > 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>multi<runtime-link>dynamic and
> <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.

Ok, understood.

- Volodya