> This is bad [but read to the end because I might change my > mind]. Suppose someone is working with a pre-release of MSVC 8.0. She > knows it has several problems, so adds appropriate workarounds to the > code. How can someone over at Microsoft is test their compiler against > the Boost CVS without workaround, other than by faking the compiler > version number?
OK you've convinced me: apart from anything else it's an easier rule to adhere to - lets just "trust the user" and have BOOST_STRICT_CONFIG disable compiler specific workarounds. > Incidentally, I think we had some kind of agreement a while back > (sparked by Thomas Witt, IIRC) that when a workaround is implemented > for the most recent compiler version, no assumption should be made > that the corresponding bug will be fixed in future versions. I don't > think my macro accounts for that, and I really don't know a good way > to cope with it. I don't think we ought to add any workarounds without > at least some way to record the most-recent version where it's known > to be needed. In theory the way to do that is (for example): #if defined(__BORLANDC__) && ((__BORLANDC__ < 0x570) || !defined(BOOST_STRICT_CONFIG)) which enables the workaround for all Borland versions, unless BOOST_STRICT_CONFIG is defined. This is consistent with the way that the existing config system works BTW, although it does present a maintenance problem (lots of compiler version checks scattered all over the place, all of which need updating when a new compiler is released). This also conflicts with your desired use case (disabling workarounds in cases where we know that it really is needed)! Round and round and round :-( John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost