> >> I don't (yet). Why do we need yet another macro which means "turn off > >> the workarounds?" Would BOOST_STRICT_CONFIG then be obsolete? > > > > I think that the idea is that BOOST_STRICT_CONFIG applies only to unknown > > compiler versions, and BOOST_DISABLE_WORKAROUNDS (do we need separate > > compiler/library macros?) would be applied unconditionally, regardless of > > whether the compiler has known defects. > > What's the use of distinguishing those? Surely the person who's doing > the testing doesn't care about whether we think we "know" that > particular compiler version?
Would you believe that I've rewritten this mail three times with the previous two having flaws (discovered just as I'm adding my sig!). Hopefully this time this is logically correct, how about this: If the config system detects a compiler version it knows about, and which it knows will likely need compiler specific workarounds, then it undef's BOOST_STRICT_CONFIG if it's set (in the compiler config files). Then we just use BOOST_STRICT_CONFIG as to determine whether to enable workarounds or not. There are now three use cases if BOOST_STRICT_CONFIG is defined: 1) We recognise the compiler, and know that it needs workarounds: disable BOOST_STRICT_CONFIG. 2) We don't recognise the compiler: assume that it is standard conforming and disable all workarounds. 3) BOOST_NO_COMPILER_CONFIG is set: so irrespective of the compiler version all workarounds will be turned off. BTW I think your BOOST_WORKAROUND macro belongs in boost/config/suffix.hpp if you want to move it there (so we all get it), and of course it needs docs adding - probably to the helper macros table in the config docs. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost