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

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-09 09:43:29

"John Maddock" <jm_at_[hidden]> writes:

>> 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 :-(

OK, now I've rewritten and re-thought this email about 5 times ;-)

I'm going to ask a controversial question: what is the point of
checking the version at all in the case above, really?  If you buy my
argument that the user surely knows what he's doing when he specifies
BOOST_STRICT_CONFIG, there's no reason not to let BOOST_STRICT_CONFIG
turn off workarounds always. In that case, the test above might as
well just be:

   # if defined(__BORLANDC__) && !defined(BOOST_STRICT_CONFIG)

And, it seems to me, if the presumption that the bug being worked
around is likely present in future versions is correct, this is better
because there's no associated maintenance cost (i.e. nobody has to
bump the version number). I think the current "accepted form" quoted
by you and Aleksey is theoretically interesting, but the version
number doesn't have much value other than as a comment. Wouldn't

   #if BOOST_WORKAROUND(__BORLANDC__, != 0) // last checked at 0x569

or

   #if BOOST_WORKAROUND(__BORLANDC__, +0x569)
   // not sure about overflow issues, so maybe not

be just as good, or maybe even better?

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution