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

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-12 13:36:38

"Paul Mensonides" <pmenso57_at_[hidden]> writes:

> ----- Original Message -----
> From: "David Abrahams" <dave_at_[hidden]>
>
>
>> David Abrahams <dave_at_[hidden]> writes:
>>
>> > How can we say
>> >
>> >  #if BOOST_WORKAROUND(__SUNPRO_CC, /*something involving 0x530 */)
>> >
>> > and have it enter the #if and warn when __SUNPRO_CC > 0x530 ?
>>
>> It's supposed to enter the #if unconditionally, of course.
>
> By "scaffolding" I meant "more lines."  It easy to cause it to error though:
>
> #define BOOST_WORKAROUND(symbol, test) (((symbol) != 0) && 1 % ((symbol)
> test ? 1 : 0))
>
> #define SYMBOL 2
>
> #if BOOST_WORKAROUND(SYMBOL, == 2) // okay
> // ...
>
> #if BOOST_WORKAROUND(SYMBOL, <= 1) // error
> // ...

Errors are not a good response here, unless of course that's done
purely as an option.

> Causing a warning, on the other hand, is a QI issue.  It depends entirely on
> whether you can find an expression that yields a warning.  For example, on
> Comeau C++:
>
> ((symbol) test ? 1 : -1) * 1U
>
> ...causes a "change of sign" warning if "(symbol) test" yields false.
> However, this doesn't work on at least some other compilers.  I tried all
> sorts of things like shifting, UINT_MAX + 1, etc., but I didn't find
> anything that issues a warning on VC (for example).
>
> You could do something like this:
>
> #if BOOST_WORKAROUND(__SUNPRO_CC, <= 0x530)
>
> #if defined(BOOST_DEVELOPER_WARNINGS) && __SUNPRO_CC > 0x530
> #pragma boost developer warning:  compiler version exceeded
> #endif
>
> // ...
>
> #endif

What's that going to do?  Nobody implements that #pragma, and only
some compilers will warn about unknown pragmas. Right?

Anyway, it's too much typing, IMO, and too easy to get wrong.

> Actually, given a known set of symbols (such as the ones used in config.hpp)
> you don't need to separate the test from the symbol:
>
> BOOST_WORKAROUND(__SUNPRO_CC <= 0x530)
>                          // ^ no comma
>
> As long as the symbols used are known, it is no problem to pull the symbol
> off the beginning (or end) of the expression.

Yeah... I think I'd rather not do that.  The version with the comma
works with any symbol and doesn't incur the kinds of maintenance costs
associated with that approach.

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