Re: [boost] Review: Config system

From: John Maddock (John_Maddock_at_[hidden])
Date: 2001-08-26 06:21:47

>I'm suggesting that it's OK for suffix.hpp to have outer EDG check, not 
>that it needs to go in each compiler's header, but that the details should

>go in edg.hpp, for the same reason that we don't put all the compiler 
>files in-line in select_compiler_config.hpp.

Got it, yes that's a good idea.

>This seems even more wrong to me after reading these remarks than it did 
>before.
>
>     1) There are many thread APIs, and the Boost Threads library may 
>support more of them over time.

Yes, but the boilerplate BOOST_HAS_THREADS won't change - it's intended
that the section in suffix.hpp only deals with the common cases that are
used by more that one compiler - platform or compiler specific macros
belong in the appropriate mini header - for example
<boost/config/platform/be.hpp> defines BOOST_HAS_THREADS unconditionally at
present.  

Perhaps I should have made this point more strongly in the comment that
accompanies that section.

That just leaves macros like BOOST_HAS_FOOTHREADS which will get added as
the boost is updated to support threading on platform foo.  Centralising
these allows all libs that need synchronisation to make use of them, and
IMO that is a good thing.

BTW if a particular primitive doesn't support threading on platform foo,
then you should end up with a #error, IMO that is a good thing, it's a
signpost that either some porting needs to be done, or that
BOOST_DISABLE_THREDAS needs to be defined - and all that implies.
>
>     2) Thread synch. support in other libraries may be useful to Boost 
>users even in cases where the Threads library does not support the local 
>thread APIs.

I would rather see the thread lib patched to support the new API rather
than have multiple synch objects defined all over the place, we should
avoid "wheel reinvention" where possible.
>
>It seems wrong that if we change the Threads library to support more 
>thread APIs, we have to update the config headers as well as updating the 
>Threads library.
>
The only config header to be patched would be the platform (or possible
compiler) mini-config, other platforms would be unaffected.

- John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/