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

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-12-11 15:08:46

----- Original Message -----
From: "Gennaro Prota" <gennaro_prota_at_[hidden]>

> 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.

It's possible with a little scaffolding.

> 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

The preprocessor library uses unversioned checks.  The maintenance cost
associated with bumping up all the versions referred to would be high.  I
think it makes a big difference with whether or not a workaround requires
using behavior that is non-compliant.  If it doesn't, an unversioned check
is better, IMHO.  At the same time, some type of "use strict mode" macro
should unilaterally force the non-workaround version.  This is a good way to
find if new compiler versions or previously untested compilers can handle
the strict code.

[snip]

> 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.

It is possible to make it generate a warning or an error if a compiler
version is higher than the specification.  Of course, you also don't have to
use the preprocessor to do this sort of thing.

Paul Mensonides