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

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-08 15:45:39

Gennaro Prota <gennaro_prota_at_[hidden]> writes:

> --- David Abrahams <dave_at_[hidden]> wrote:
>> Gennaro Prota <gennaro_prota_at_[hidden]> writes:
>> 
>> > On Sun, 08 Dec 2002 12:34:48 -0500, David Abrahams
>> > <dave_at_[hidden]> wrote:
>> >
>> > [snip]
>> >>> // untested
>> >>> #define BOOST_PSEUDO_IS_DEFINED(symbol) BOOST_JOIN(symbol, 1)
>> >>> #define BOOST_WORKAROUND(symbol, test) \
>> >>>          (BOOST_PSEUDO_IS_DEFINED(symbol) && symbol test)
>> >>
>> >>This will fail if "symbol1" is defined, won't it?
>> >
>> > Oops, due to the font used when reading mails from Yahoo, I thought
>> > this was a typo for "symbol" :-s Yes, you are right. It wasn't
>> > intended as a solution to
>> >
>> >>>  b) "hides" possible problems in the (unlikely, granted) case that
>> >>>      X is undefined but X1 is and you write:
>> >>>
>> >>>            BOOST_WORKAROUND(X, test)
>> >>>
>> >>>     (the result "unexpectedly" depends on the expansion of X1).
>> 
>> Actually, I tested my solution for that problem and it was OK. That's
>> the reason I was pasting that long BOOST_NUMERIC_DEFINED_SUFFIX symbol
>> to it: the idea was that probably nobody defines the
>> __SUNPRO_CCBOOST_NUMERIC_DEFINED_SUFFIX symbol, for example.
>
> 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.

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

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 

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

    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.

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