On Sun, 08 Dec 2002 15:45:39 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>Gennaro Prota <[EMAIL PROTECTED]> 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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
