From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-12-10 04:50:41
David Abrahams wrote:
> "John Maddock" <jm_at_[hidden]> writes:
> > 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).
Actually, they don't - as far as BOOST_STRICT_CONFIG is not defined (I
wonder if anybody uses it at all), the checks will continue to work.
Updating them is a strictly volunteer activity :)
> > 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)
Well, expect that the above doesn't let you distinguish whether the bug is
(was) really present in the latest known version of the compiler, or the
person who wrote the above was just sloppy/careless ;).
> 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.
Hmm, looks like a 100% correct observation to me.
> #if BOOST_WORKAROUND(__BORLANDC__, != 0) // last checked at 0x569
> #if BOOST_WORKAROUND(__BORLANDC__, +0x569)
> // not sure about overflow issues, so maybe not
> be just as good, or maybe even better?
I am sold on this one :).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk