From: John Maddock (jm_at_[hidden])
Date: 2002-12-09 06:31:09
> 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) ||
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 :-(
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk