On Mon, 09 Dec 2002 09:43:29 -0500, David Abrahams <[EMAIL PROTECTED]> wrote:
>"John Maddock" <[EMAIL PROTECTED]> writes: > >> In theory the way to do that is (for example): >> >> #if defined(__BORLANDC__) && ((__BORLANDC__ < 0x570) || >> !defined(BOOST_STRICT_CONFIG)) >> >[...] >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) > >be just as good, or maybe even better? Yes. It would be nice if we could come up with an implementation of BOOST_WORKAROUND or another macro, let's say BOOST_UNVERSIONED_WORKAROUND, that generates a warning or (more realistically) an error when you invoke it with e.g. BOOST_UNVERSIONED_WORKAROUND(__BORLANDC__, 0x569) and __BORLANDC__ expands to a value greater than 0x569. That would be a reminder for the maintainer to either bump 0x569 to a higher value (i.e. to update the "last checked comment") or change the invocation to BOOST_WORKAROUND(__BORLANDC__, <= 0x569)). But off the top of my head I can't think any way to do that. The point is of course that if the compiler is fixed an unversioned check will still use the workaround, silently. Well, there are special cases where this doesn't hold; e.g. one of the tests we have in dynamic_bitset: had I written #if BOOST_WORKAROUND(BOOST_MSVC, |1200) // in certain situations VC++ requires a redefinition of // default template arguments, in contrast with 14.1/12 // # define BOOST_WORKAROUND_REPEAT_DEFAULT_TEMPLATE_ARGUMENTS #endif I would have got a warning with Everett; and then, if they didn't mind backward compatibility I would have got an error, but that's because in this case the workaround consists in using non-conforming code. Very often instead, it consists in giving up using a certain feature, or using it in a limited way. Better removing it as soon as possible then... Such a macro would help the programmer to not "forget" to check whether the workaround is still needed. As an alternative we could decide to ban unversioned checks at all. I don't know, it depends on whether we consider more important avoiding the mainteinance burden or exploting the compiler (or library) capabilities. Genny. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost