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

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2002-12-11 14:29:43

On Mon, 09 Dec 2002 09:43:29 -0500, David Abrahams
<dave_at_[hidden]> 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))
>>
>[...]
>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.