[boost] Re: new macro - BOOST_WORKAROUND(symbol, test)

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2002-12-08 16:43:07

On Sun, 08 Dec 2002 15:45:39 -0500, David Abrahams
<dave_at_[hidden]> wrote:

>Gennaro Prota <gennaro_prota_at_[hidden]> writes:
>> Well, there's no problem with __SUNPRO_CCBOOST_NUMERIC_DEFINED_SUFFIX, just
>> with __SUNPRO_CC1.
>
>We seem to be talking past one another. I've been trying to tell you
>that preventing expansion into __SUNPRO_CC1 was the very reason I used
>BOOST_NUMERIC_DEFINED_SUFFIX.

Ah! Are you saying you think BOOST_NUMERIC_DEFINED_SUFFIX may remain
unexpanded? Indeed, as far as I understand the preprocessing, it
always becomes 1. 

>>> Well, then I tested your solution and it was also OK on all the
>>> compilers I have on my machine:
>>> 
>>>     # include <boost/config.hpp>
>>> 
>>>     #define BOOST_PSEUDO_IS_DEFINED(symbol) BOOST_JOIN(symbol, 1)
>>>     #define BOOST_WORKAROUND(symbol, test) \
>>>              (BOOST_PSEUDO_IS_DEFINED(symbol) && symbol test)
>>> 
>>>     # define SOME_COMPILER_MACRO1 0
>>> 
>>>     # if BOOST_WORKAROUND(SOME_COMPILER_MACRO, > 0)
>>>     #  error whoops 
>>>     # endif 
>>
>> As I said, when SOME_COMPILER_MACRO1 is defined but SOME_COMPILER_MACRO isn't
>> then the result depends on the expansion of SOME_COMPILER_MACRO1 (and possibly
>> on the test, of course). In this case the condition of the #if becomes:
>>
>>    (0 && SOME_COMPILER_MACRO > 0)
>>
>> and then, of course
>>
>>    (0 && 0 > 0)
>>
>> Now, try defining
>>
>>  #define SOME_COMPILER_MACRO1  5
>>
>> and change the test e.g. to <= 1200
>
>Sure, I did. I also had a test there which you snipped from your
>email.

Let me explain again what I meant: the reason why your example doesn't
trigger the #error is that you define SOME_COMPILER_MACRO1 to zero
(and because of the test ">0"). Actually, you "fall" into using
SOME_COMPILER_MACRO1 but, luckily, the whole test yields false anyway.
To have an unexpected #error I suggested you to try:

  #define SOME_COMPILER_MACRO1 5

  #if BOOST_WORKAROUND(SOME_COMPILER_MACRO, <= 1200)
  # error whoops 
  #endif

>Why don't you run some tests yourself? Try this:
>
>    # include <boost/config.hpp>
>
>    #define BOOST_PSEUDO_IS_DEFINED(symbol) BOOST_JOIN(symbol, 1)
>    #define BOOST_WORKAROUND(symbol, test) \
>             (BOOST_PSEUDO_IS_DEFINED(symbol) && symbol test)
>
>    # define SOME_COMPILER_MACRO1 1
>
>    # if BOOST_WORKAROUND(SOME_COMPILER_MACRO, > 0)
>    #  error whoops 
>    # endif 

Yeah! You have no error here because after all the macro expansions on
the #if condition you have

  (1 && SOME_COMPILER_MACRO > 0)

but then the undefined identifier SOME_COMPILER_MACRO is replaced with
zero! That's why I suggested to change the test.

>    # if !BOOST_WORKAROUND(SOME_COMPILER_MACRO1, == 1)
>    #  error whoops2
>    # endif

Well, here you just end up with

   !(11 && 1 == 1)

so no error either.

>    int main()
>    {
>        return 0;
>    }
>
>
>> [...]
>>> BOOST_PP_CAT has several workarounds for broken compilers, and I
>>> wanted to get it right first before worrying about that particular
>>> dependency.
>>
>> Yeah, I noticed that. I don't know what problems do they solve
>> though so I'm not sure if they are needed in the case of
>> BOOST_WORKAROUND. Maybe they have just to do with passing empty
>> arguments?
>
>We'll have to ask Paul I guess. However, empty arguments are a very
>real concern for the problem at hand.

The precondition is that the first argument of BOOST_WORKAROUND must
be either undefined or expand to something, i.e. you can't use for
instance this

#define X

so I don't see any macro invocation where there's an empty sequence of
tokens used as argument. Do you?

Genny.