Re: [boost] [Config] Testing instructions for compiler vendors

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) ||
!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