> I'm still not sure that BOOST_STRICT_CONFIG is the right macro to determine if > workarounds are enabled or not, but if John agrees then I'm happy with it. > Regardless of what macro determines which BOOST_WORKAROUND is used, I like > the above definition (+ dumb compiler workarounds).
OK let me try and explain what I had in mind when those macros were introduced: BOOST_NO_XXX_CONFIG: disables automatic configuration of compiler/stdlib/platform, generally used in conjunction with a customised boost/config/user.hpp to prevent dependencies on the config system. Should *not* disable compiler workarounds. BOOST_STRICT_CONFIG: defined when the user is testing a new compiler version (one newer than boosts automatic config is aware of, and which may or may not require configuration), should disable compiler specific fixes only if the compiler version is greater than the last version we've tested. Remember these were designed for users, not compiler vendors. Maybe we need something new for those folks: something like BOOST_NO_WORKAROUNDS or whatever, that disables all compiler workarounds? To keep things centralised BOOST_NO_WORKAROUNDS should be defined by the compiler config when the compilers version is greater than the last known version and BOOST_STRICT_CONFIG is set, then boost workaround-code need only check for the presence of BOOST_NO_WORKAROUNDS or whatever in addition to the compiler version. How does this sound? John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
